FWIW, I'm not sure your commit helped, at least, it seems to be worse for some usecases: (PyPy default vs 2.3.1): $ ./pypy-c -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 1.09 msec per loop $ ./pypy-c -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 1.1 msec per loop $ ./pypy-c -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 1.11 msec per loop $ pypy -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000}) 1000 loops, best of 3: 503 usec per loop $ pypy -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 491 usec per loop $ pypy -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 498 usec per loop Alex On Fri, Aug 29, 2014 at 9:52 AM, Phyo Arkar <phyo.arkarlwin@gmail.com> wrote:

Thanks a lot! i am waiting to switch to PyPy.

Also there is one performance problem. I haven't profile it properly yet just from looking at Chrome DEV Console.

A simple Tornado async (callback) + pymongo + motor + reading 100 records from db and returning them in json , in Python its takes only 1 ms in Pypy it takes 4-6 ms

I will make proper benchmark on it when i get time. and find which part is slowing down. But may be you can guess where it is slowing?

On Fri, Aug 29, 2014 at 10:34 PM, Armin Rigo <arigo@tunes.org> wrote:

...

Hi Phyo,

Thanks for the report! I may have fixed it in e80c25f01061. Please try it out with tomorrow's nightly build.

A bientôt,

Armin.

---

pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

Hi Alex, On 30 August 2014 08:43, Armin Rigo <arigo@tunes.org> wrote:

went down from 5.8ms per loop to 208us. However, I see that running the same example with 10000 ascii chars went up from 41.4us to 139us. Time to tweak.

Tweaked! See 65ac482d28d6. This was because if you used this kind of code in RPython: for c in unistring: if c >= u' ': ... then the comparison works, but is done by converting the character back to a full unicode string and calling ll_strcmp()... so the big overhead was caused half by the conversion costs and half by the extra GC pressure. A bientôt, Armin.

Wow, nice catch! Alex On Mon, Sep 1, 2014 at 3:31 AM, Armin Rigo <arigo@tunes.org> wrote:

Re-hi,

On 1 September 2014 12:20, Armin Rigo <arigo@tunes.org> wrote:

...

Tweaked!

Note that the final result is 33% faster in your example.

Armin

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

Hi, On 1 September 2014 17:06, Phyo Arkar <phyo.arkarlwin@gmail.com> wrote:

Thanks a lot. I haven't get to test lastest commit yet. So in that , attached benchmark in pypy is running faster than python now?

Yes, for the utf-8 test (the tests with "double" didn't change). Here is what I get on Linux 64: $ pypy-c-r73264-jit benchmark.py Array with 256 doubles: simplejson encode : 3871.15257 calls/sec simplejson decode : 14651.04979 calls/sec Array with 256 utf-8 strings: simplejson encode UTF : 1393.29238 calls/sec simplejson decode UTF : 276.03465 calls/sec $ python benchmark.py # 2.7.3 Array with 256 doubles: simplejson encode : 3469.44902 calls/sec simplejson decode : 12419.69240 calls/sec Array with 256 utf-8 strings: simplejson encode UTF : 1278.32368 calls/sec simplejson decode UTF : 355.18049 calls/sec A bientôt, Armin.

FWIW, I'm not sure your commit helped, at least, it seems to be worse for some usecases: (PyPy default vs 2.3.1): $ ./pypy-c -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 1.09 msec per loop $ ./pypy-c -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 1.1 msec per loop $ ./pypy-c -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 1.11 msec per loop $ pypy -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000}) 1000 loops, best of 3: 503 usec per loop $ pypy -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 491 usec per loop $ pypy -mtimeit -s "import json" "json.dumps({u'': u'abcdef' * 10000})" 1000 loops, best of 3: 498 usec per loop Alex On Fri, Aug 29, 2014 at 9:52 AM, Phyo Arkar <phyo.arkarlwin@gmail.com> wrote:

Thanks a lot! i am waiting to switch to PyPy.

Also there is one performance problem. I haven't profile it properly yet just from looking at Chrome DEV Console.

A simple Tornado async (callback) + pymongo + motor + reading 100 records from db and returning them in json , in Python its takes only 1 ms in Pypy it takes 4-6 ms

I will make proper benchmark on it when i get time. and find which part is slowing down. But may be you can guess where it is slowing?

On Fri, Aug 29, 2014 at 10:34 PM, Armin Rigo <arigo@tunes.org> wrote:

...

Hi Phyo,

Thanks for the report! I may have fixed it in e80c25f01061. Please try it out with tomorrow's nightly build.

A bientôt,

Armin.

---

pypy-dev mailing list pypy-dev@python.org https://mail.python.org/mailman/listinfo/pypy-dev

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

Hi Alex, On 30 August 2014 08:43, Armin Rigo <arigo@tunes.org> wrote:

went down from 5.8ms per loop to 208us. However, I see that running the same example with 10000 ascii chars went up from 41.4us to 139us. Time to tweak.

Tweaked! See 65ac482d28d6. This was because if you used this kind of code in RPython: for c in unistring: if c >= u' ': ... then the comparison works, but is done by converting the character back to a full unicode string and calling ll_strcmp()... so the big overhead was caused half by the conversion costs and half by the extra GC pressure. A bientôt, Armin.

Wow, nice catch! Alex On Mon, Sep 1, 2014 at 3:31 AM, Armin Rigo <arigo@tunes.org> wrote:

Re-hi,

On 1 September 2014 12:20, Armin Rigo <arigo@tunes.org> wrote:

...

Tweaked!

Note that the final result is 33% faster in your example.

Armin

-- "I disapprove of what you say, but I will defend to the death your right to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) "The people's good is the highest law." -- Cicero GPG Key fingerprint: 125F 5C67 DFE9 4084

Hi, On 1 September 2014 17:06, Phyo Arkar <phyo.arkarlwin@gmail.com> wrote:

Thanks a lot. I haven't get to test lastest commit yet. So in that , attached benchmark in pypy is running faster than python now?

Yes, for the utf-8 test (the tests with "double" didn't change). Here is what I get on Linux 64: $ pypy-c-r73264-jit benchmark.py Array with 256 doubles: simplejson encode : 3871.15257 calls/sec simplejson decode : 14651.04979 calls/sec Array with 256 utf-8 strings: simplejson encode UTF : 1393.29238 calls/sec simplejson decode UTF : 276.03465 calls/sec $ python benchmark.py # 2.7.3 Array with 256 doubles: simplejson encode : 3469.44902 calls/sec simplejson decode : 12419.69240 calls/sec Array with 256 utf-8 strings: simplejson encode UTF : 1278.32368 calls/sec simplejson decode UTF : 355.18049 calls/sec A bientôt, Armin.