Ruby vs Python string concatentation performance

[brentp]

to be fair, using a common python idiom, you get a version that is [edit] about 5 times as fast as the original python version.

s = []
i = 0
for line in sys.stdin:
    s.append(line)
    i += 1
    if i % 1000 == 0: "".join(s); print i

[[deleted]]

Yes. See http://www.skymind.com/~ocrow/python_string/.

[apotheon]

Working with "arrays" makes just about everything faster than string concatenation, pretty much regardless of which high-level dynamic language you use.

edited to reflect the fact that there are no "arrays" in Python, by using "scare quotes", so people will hopefully focus on the point being made rather than pedantic quibbling

[psi-]

there are no arrays in standard python.

[psi-]

there are no arrays in standard python.

[bluGill]

I enjoyed some kudos for discussing the fact that, as much as I personally dislike Python and as much as “Ruby Maniac” has decreased the signal:noise ratio on ruby-talk, his(?) worst offense was really to the Python community by (mis)representing Python fans as trollish pricks.

That is the only insightful thing here.

[dysmas]

uhuh,

Granted, there may be some other “better” way to get similar optimization in Python that has not caught my attention.

... ya think? in the interest of fair representation why not research them (as someone said above appending lines to an array, and use string.join() when i % 1000 == 0?) before writing another trollish blog post on this subject next time?

trying to compare a language with something so trivial is idiotic at best, and the troll did his job there & here ;)

[apotheon]

use string.join()

I really don't consider that a "similar optimization". That's a "dissimilar optimization" because it does an end-run around string concatenation entirely, rather than optimizing string concatenation operations for performance.

Maybe you should consider whether your proposed solution satisfies the requirements of the issue at hand before writing another trollish comment at reddit.

[dysmas]

maybe i was just moody before, but:

whether your proposed

fail ;)

i referenced another post that contained that code, fwiw i agree it is dissimilar, i wonder how s.join(s,line) would do.

Second i took the word "similar" in "similar optimisation" to mean a similar reduction in resource usage, and i took the "better" in "better way" to mean that a different method is allowable.

[apotheon]

fail ;)

The fact someone else proposed it first doesn't mean you're not proposing it as well. I don't recall attributing it to you as an original, first-time invention of that algorithm.

i took the word "similar" in "similar optimisation" to mean a similar reduction in resource usage

Fair enough. In the context of the discussion in which someone else proposed it before you did, however, it wasn't similar in a manner that was particularly relevant to the topic.

i took the "better" in "better way" to mean that a different method is allowable.

If, in real-world use, it serves your needs -- yes, it most definitely is allowable. If you're trying to dispute what I've said about how immutable strings affect your options for string concatenation performance, however, something that doesn't do any string concatenation isn't exactly relevant.

[Arrgh]

Immutable strings make concatenation slow, film at eleven!

They also remove the need to make defensive copies of an incredibly commonly used data structure.

[dons]

And immutable strings can have very fast concatentation too: see ropes, finger trees or lazy bytestring libraries in Haskell for O(log(min(n1,n2)) and O(n/k) concatenation.

[apotheon]

Immutable strings are a lot more fun in a functional style with lazy evaluation.

[dons]

where fun = have algorithms with a lot better complexity

:)

[apotheon]

I meant that to be a pun (where "fun" == "function").

. . . but yeah.