Hacker News new | past | comments | ask | show | jobs | submit login

Be very suspect of the results - for instance in python land you have:

wsgi:

    import ujson
    ...
    response = {"message": "Hello, World!"}
    ...    
tornado:

    obj = dict(message="Hello, World!")
    self.write(obj)
    
What you have is the slower way to contruct a dictionary and then passing to the Python native JSON vs. a C optimized JSON for output.



Although this is Round 7, we have no delusions that there is not a lot of room for improvement (particularly in the toolset, although that's a separate matter). If there are tuning tweaks, we'd love to receive a pull request.


Just to expand on that (I had to check it for myself) - in my ipython (ageing core2, two cores at around 6k "bogomips"):

    %timeit d={"message": "Hello, world"}
10000000 loops, best of 3: 103 ns per loop

    %timeit d=dict(message="Hello, world")
1000000 loops, best of 3: 298 ns per loop

    sys.version
    Out[24]: '2.7.3 (default, Jan  2 2013, 13:56:14) \n[GCC 4.7.2]'
So, pretty big difference.


Yes, but!

At 103ns per iteration, you can do 9.7 million iterations per second. At 298ns per iteration, you can do 3.4 million iterations per second.

Let's look at the wsgi numbers for json serialization:

  wsgi-nginx-uWSGI: 109,882 rps
  bottle-nginx-uWSGI: 65,793 rps
  wsgi: 65,755
  ..
Now, let's look at the best case comparison: 109,882 rps vs 3.4 million iterations per second. Is cutting iteration time down to 1/3 significant (298ns vs 103ns)? Yes. Is it significant in the overall context? No.

With a 31x difference between 109,882 and 3.4 million* (and, since this is comparing to an i7, that 31x is probably closer to the ballpark of 100x), this simply isn't likely to be the place where optimization will help much. Put simply, the {"message": "Hello, world"} vs dict(message="Hello, world") cost difference is likely insignificant when compared to the cost of the rest of the request.

With that said, this sounds like a change that should be committed as part of a pull request! Why? A couple of reasons:

- It may still help the performance in a minor way (at the very least, it shouldn't hurt it)

- We prefer idiomatic code and, assuming the literal {} notation - vs dict() - is idiomatic for such a case, this would be a good change.

Your point about this is also interesting:

  What you have is the slower way to contruct a dictionary
  and then passing to the Python native JSON vs. a C 
  optimized JSON for output.
Please do consider a pull request for both. We love community contributions.

* Yes, I know these aren't directly comparable numbers, but they compare well enough in this case.

Edit: Fixed the literal {} vs dict() mixup that e12e pointed out in my comment.


Note, I'm not the one that noticed this, I just tried the difference between literal construction "{}" and using dict().

Good points on the overall (likely) impact on the benchmark(s).

> We prefer idiomatic code and, assuming dict() is idiomatic for such a case, this would be a good change.

I think you mix up two things here: dict() is slower (presumably method look up and maybe class instantiation? Just guessing here) -- and I'd say using the literal notation is in general more idiomatic:

http://docs.python.org/2/tutorial/datastructures.html#dictio...


Oops, yes. I did mix up dict vs the literal version in the comparison. Thank you for the correction.

And yes, I noticed that you weren't the one that noticed the original possible performance issue. What I do appreciate is that you actually went and tested the performance difference.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: