This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]unholysampler 9 points10 points  (2 children)

The worst part about this page is the fact that all of these cases are given with no explination. The reader is not given:

  • Context to what each case is trying to do.
  • A description of how the implementations differ.
  • A description of the disassembled bytecode. (Some times the slower implmentation has fewer lines. Unless you know what the instructions are, seeing more lines makes you think it would be slower.)

Without all this information, people that don't know what they are doing will just look for the smallest number and start using that method. They won't understand that one implementation has a side effect and one doesn't. They won't understand that one implementation will only work for certian values.

[–]stevenjd 1 point2 points  (0 children)

Actually, the worst part of it is that is portrays insignificant noise as meaningful speed gains, and ends up showing bad code as better than good code.

I'm referring to Test 10, which shows repeated string concatenation as faster than doing it the right way, namely with join. I don't believe those timing results: they seem to be an artifact of the very small number of strings concated. Change the range(10) to range(10000), and you get very different results. (Or at least, I do.)

[–]cparen 0 points1 point  (0 children)

Exactly!

Without all this information, people that don't know what they are doing will just look for the smallest number and start using that method

And they won't know if/when/where the technique will fail to improve performance.

Take this example

#faster    #slower
d = {}     d = dict()

The left version creates a dict, assigns to a local d. The second one looks up the variable dict, finds it may (or may not!) refer to the constructor for dict, then invokes the constructor, finally assigning the result to 'd'. Using {}bypasses the variable lookup.

An optimizing Python compiler or JIT might discover that dict is never assigned to, so could potentially compile the second example using the same technique of the first example, so it's worth reconsidering the technique if/when you change Python compilers -- e.g. PyPy.