Task Log: Performance Contribution

I started with Rspack, Lynx, and PrimJS, which Lynx is built on. I was also interested in Rune, but put it off because it was GPU-based and seemed too early-stage.

AI made all the code changes. I didn’t think through the optimization strategy myself. I reviewed the resulting changes locally for correctness.

I forked all three under my account and had AI set up a Gungraun-based optimization skill in each repository. Measurements would run in the fork’s CI, and changes would only be submitted upstream after my approval.

• Rspack setup
• Lynx setup
• PrimJS setup

When I looked at the results, the benchmarks were all mocks. Maybe my prompt had been too simple. So I asked it to make all the code available for profiling.

First, fix the Gungraun CI in my fork so it can profile everything.

I ran this for all three projects in parallel, but it took a while because the work included actual verification. For PrimJS, the setup was updated to show function names and call costs, and accept other JavaScript files as workloads.

I submitted the first PrimJS PR. It reduced unnecessary conversions in integer postfix increment and decrement operations.

I also left a comment asking whether AI-assisted performance contributions would be welcome. I said I would use AI for almost everything, but verify every PR I sent.

The first PR convinced me that this approach worked, so I asked on X whether any other projects wanted contributions like these. I also asked the Rspack team whether a large number of AI-assisted performance contributions would be welcome, and they agreed.

With this approach, PRs keep coming until AI can no longer find problems in the benchmark data. Each PR is focused, but there can be a lot of them. That was why I asked beforehand whether sending a huge number of useful PRs would be okay.

A little later, the second PrimJS PR was ready. It reused an existing formatter for integer-to-string conversion. I personally reviewed the changes before approving PR creation. Just in case, I also ran a security review in T3 Code.

Review whether https://github.com/lynx-family/primjs/pull/443 could introduce any security issues.

The Rspack profiling setup was ready next. It had been extended to measure 59 existing Rust benchmark cases.

I started the optimization run right away. Since Rspack is a large project, I added parallel testing to the prompt.

$gungraun-optimize First, profile the code, then use subagents to test each optimization idea in parallel. Run up to five at a time.

The skill seemed to work well, so I generalized it for use across projects. Then I forked Ada to try it on ada-url/ada too.

The third PrimJS PR reduced heap allocations during string processing. I reviewed it, found the diff small and well scoped, and approved PR creation.

I still hadn’t received approval from the Lynx team, though. I decided to stop sending PRs to PrimJS and Lynx and wait for the three existing PRs to merge.

I submitted the first Ada PR, which removed a temporary buffer during path encoding. The second PR reduced unnecessary allocation when converting IPv6 addresses to strings. Its small diff made it easy to review.

Another candidate removed domain validation, but I couldn’t tell whether that was correct, so I didn’t approve a PR for it. The commit is still in my fork.

Next came a PR simplifying string searches. The change looked clean when I reviewed it, and instruction counts were unchanged or lower in every measured case, so I approved it.

I went off to relax for a bit. When I came back, Ada #1335 had merged.

CodSpeed reported regressions on the other two PRs. On inspection, the benchmarks flagged as slower didn’t execute the changed code paths. There was also a warning that the comparisons used different runner types. I left comments on both PRs. They looked unrelated to the changes, but I also had AI double-check.

On the Rspack side, a change to swc-next was needed, so I submitted a PR there. It reduced unnecessary operations in SIMD mask conversions.

The skill’s performance threshold was 1%, but expecting a local optimization to improve an entire project like Rspack by 1% seemed like asking too much. So I told it to ask me about each candidate again.

After that, I submitted two Rspack PRs: one avoiding unnecessary string searches during path processing, and one changing how small export lists are searched.