Explore PyPy, mypyc, Cython

[jpmckinney]

Original description is from when issue was only about PyPy.

We do a fair bit of JSON deserializing (and serializing). On CPython, we use orjson. The json standard library on PyPy is slower, but not by a huge amount, so using PyPy could still be a performance gain. In principle, orjson could be made to support PyPy. https://github.com/ijl/orjson/issues/90#issuecomment-2380389948

Candidates with heavy processing:

• Kingfisher Process (ocdskit, ocds-merge), though also https://github.com/open-contracting/data-registry/issues/292 for data registry
• Pelican, though also https://github.com/open-contracting/data-registry/issues/291 for data registry
• Data Registry, though flattener worker uses Rust and exporter worker is (expected to be) mostly I/O

Next steps

• [ ] Do some benchmarks between CPython and PyPy for our own code (keep in mind that JIT needs to be warm – works well for long-running workers)

PyPy profiler support

If PyPy really is faster than CPython for our workloads, then there is no point profiling and optimizing on CPython. So, we'd need profilers on PyPy.

Supported

• standard library (cProfile, profile, timeit, tracemalloc)
• vmprof https://vmprof.readthedocs.io/en/latest/ NEW
• pprofile https://github.com/vpelletier/pprofile/blob/master/setup.py#L40

Memory

• memory_profiler

TBD

• austin
• psrecord

Not supported

• scalene https://github.com/plasma-umass/scalene/discussions/248 (support regressed)
• py-spy https://github.com/benfred/py-spy/issues/484
• yappi https://github.com/sumerc/yappi/issues/175
• pyinstrument https://github.com/joerick/pyinstrument/issues/55
• line-profiler https://github.com/pyutils/line_profiler/issues/187

Memory

• memray https://bloomberg.github.io/memray/supported_environments.html#supported-python-interpreters
• filprofiler https://github.com/pythonspeed/filprofiler/issues/25

---

Comparison and discussion: https://github.com/plasma-umass/scalene/issues/423

[jpmckinney]

PyPy disadvantages:

• Not all libraries support PyPy (orjson, in our case)
• Lags Python versions (e.g. it's currently equal to 3.10)
• Perf tools are not as mature (corroborated above)
• Uses x64_64 emulation (slow) on M1

Useful review of other compilers, followed by mypyc content https://glyph.twistedmatrix.com/2022/04/you-should-compile-your-python-and-heres-why.html

These tools benefit from comprehensive (and narrow, i.e. few Any) typing. To add types, can try:

• infer-types
• autotyping
• packages at https://stackoverflow.com/questions/50416444/automatically-generating-python-type-annotations

Other compilers:

• Cython
  • Disadvantages: To see the greatest performance improvement (e.g. C-like), we might need to
  • Use its specific types like cython.int instead of int (would a pre-processor to replace type annotations work at the build stage? I assume not), or
  • Write in Cython (increases contribution barrier and maintenance burden – but, if the alternative is rewriting it all in Rust, it might make sense to use Cython).
• mypyc
  • Expected to have a moderate performance improvement.
  • Like all tools, involves rewriting some code, so it depends on how many changes are needed. https://ichard26.github.io/blog/2022/05/compiling-black-with-mypyc-part-1/
  • Disadvantages: Correctness bugs (these could also affect our dependencies – need good tests that not only test our logic but the logic we depend on in dependencies, unless the dependencies themselves have good tests)
  • https://github.com/mypyc/mypyc/issues/1035
  • https://github.com/mypyc/mypyc/issues/1046
• Codon
  • Disadvantages: Too limited. Need to write Codon-specific code like from python import os to do file access. https://docs.exaloop.io/codon/general/roadmap
• Nuitka
  • Disadvantages: Performance is not the goal. Its performance improvement is inconsistent or minimal.

Worth trying out PyPy and mypyc, as they can more or less work with existing code. Can still consider Cython in cases where the alternative is a full rewrite in Rust. Can try these on ocds-merge for learning.