Oh, hi [*] - I had Claude add the rust speedup to . Appears to have worked, 2x...
Oh, hi #MARC [*] - I had Claude add the rust speedup to #pymarc. Appears to have worked, 2x to 6x faster depending on scenario.
[*] MARC is a very old serialization format that became popular with libraries.
Self-replies
- did not make PR to main project, it is a fork. Also these analogous libraries often side by side, e.g. prefixed with c or r.
- I told it to make the legacy tests pass, as well as write many, many more tests
- Also had it write up a sample app
- Had 4 different frontier bots do code review & had Opus respond to code review.
- Only 2x faster? It was because I set the constraint that it had to be a drop in replacement. That limits improvements.
- I did try to have the bot explain it to me
- 2/3 of the perf that pymarc leaves on the table is not using orjson and lxml. That's just setting coal on fire.
- 1/3 of the perf is rust code that looks very similar to the python code
Will it be a net improvement? I don't know. Native code costs more to compile, but when it runs it is much cheaper in terms of electricity. Windows 98 machines were like little space heaters. It's complicated, but native code wrapped in python is electric efficient.
I am tempted to do cmarc and if I can think up a suitable reason, ohimarc would be a good follow on after that.