|
Size: 642
Comment:
|
Size: 1164
Comment: lil cleanup
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 2: | Line 2: |
| ================================== | |
| Line 12: | Line 13: |
| jbaker & thobe's JavaOne '08 talk: `Jython Implementing Dynamic Language Features For The Java Ecosystem`_ |
|
| Line 14: | Line 17: |
| Our algorithms are not always the problem, sometimes it's memory allocations that slow you down | Our algorithms are not always the problem, sometimes it's memory {de}allocations that slow you down |
| Line 16: | Line 19: |
| Frame creation -------------- |
* dict allocation PyStringMap/PyDictionary pay a penalty on allocation now that they're backed by ConcurrentHashMap. We could probably tweak the ConcurrentHashMap initialCapacity, concurrentLevel to reduce this cost * Frame creation |
| Line 19: | Line 27: |
.. _`Jython Implementing Dynamic Language Features For The Java Ecosystem`: http://developers.sun.com/learning/javaoneonline/2008/pdf/TS-6039.pdf?cid=925321 |
Performance Enhancements Resources
Jython benchmarks (from PyPy's suite): http://freya.cs.uiuc.edu/~njriley/benchmark.html
Benchmark plots (currently broken): http://freya.cs.uiuc.edu/~njriley/plots.html
Ideas
jbaker & thobe's JavaOne '08 talk: Jython Implementing Dynamic Language Features For The Java Ecosystem
GC Expense
Our algorithms are not always the problem, sometimes it's memory {de}allocations that slow you down
- dict allocation
PyStringMap/PyDictionary pay a penalty on allocation now that they're backed by ConcurrentHashMap. We could probably tweak the ConcurrentHashMap initialCapacity, concurrentLevel to reduce this cost
- Frame creation
Frames are allocated for every Python method call, which is a GC expense. CPython (and JRuby?) recycle frame objects. Reducing the number of fields on the frame can also help (but this likely isn't possible)