Adaptyst sprints #4 and #5: summary + AI assistance notice

Featured image based on the one from Magnific

The fourth Adaptyst sprint at CERN took place between 2-24 July 2026 and the following fifth one was carried out between 27 July – 12 August 2026. The edge dates were different from usual ones due to the vacation of the Adaptyst main R&D person in the week of 13 July.

The following public issues were scheduled to be performed (the order here may not reflect the actual one):

Additionally, 2 CERN-internal issues were originally scheduled across the sprints, but these were eventually moved out of the scrum-based flow due to their expected deliverables not being strictly related to Adaptyst development.

AI assistance

You may notice that some tasks have an “AI-assisted” tag. This means that they were attempted using an AI coding agent. All assisted commits are marked appropriately in the repositories with an indication of a specific agentic harness and model used (the Linux kernel format serves as the baseline). In the sprints discussed here, this is mostly OpenCode and OpenAI GPT-5.6, with the exact variant noted in each applicable commit. Harnesses and models may change in the future.

Please be assured that:

  • All AI-generated work is reviewed by a human Adaptyst developer.
  • Polishes are made by a human Adaptyst developer wherever needed.
  • Outside of code, a notice about AI usage is added to all Adaptyst resources with AI-generated/AI-assisted elements.

Add Adaptyst Analyser API and document the code regionisation support in linuxperf

The implementation of the first version of the Adaptyst Analyser API was completed and documented during the last two sprints. Similarly, the code regionisation support in the linuxperf module announced some time ago was also properly documented.

Thanks to the above, the community can benefit now from these new features as part of the latest development releases of Adaptyst and the related tooling.

Add separation of Adaptyst-related stuff polluting performance analysis results

While investigating recent performance regression in one of the R&D software pieces worked on by the ATLAS experiment at CERN, it turned out that the overhead added to a profiled program by calling Adaptyst API methods might be significant enough to distort performance analysis results. Therefore, it became necessary to make Adaptyst clearly indicate to a user how many resources are / how much time is actually spent on Adaptyst-API-related activities. This resulted in adding the aforementioned task to sprint #5 and prioritising it.

The task is completed now: all Adaptyst API calls are timed and the timing information is gathered and saved by Adaptyst automatically during performance analysis, regardless of modules used. It will form part of the next development release of Adaptyst and the relevant Adaptyst-team-made modules.

adaptyst-analyser-linuxperf timeline rendering optimisation

The performance regression investigation mentioned above uncovered also one issue in the linuxperf Adaptyst Analyser module: if there are too many off-CPU regions captured during profiling, the JavaScript library used for rendering the timeline view starts to freeze. At the same time, the already-established workaround of off-CPU region sampling on the client side resulted in much lower accuracy and thus usefulness of the performance analysis results obtained as part of the investigation.

Because of the above, the overhaul of timeline rendering in adaptyst-analyser-linuxperf was urgently required, so the new task was added to sprint #5 and prioritised along with the Adaptyst-related pollution separation discussed in the previous section. This is also completed now: a new canvas-based custom renderer in JavaScript was introduced (see the repository here) and integrated into the linuxperf Adaptyst Analyser module. It will form part of the next development release, where adaptyst-analyser-nvgpu will also benefit from the novel renderer.

Make a new TUI (terminal user interface)

The current terminal user interface of Adaptyst is basic and doesn’t show real-time information related to attached modules and a workflow being analysed. While this is probably fine for non-interactive usage (such as in scripts and CI/CD pipelines), it worsens the user experience in other cases.

An AI-assisted effort towards developing a new interactive TUI was started during sprint #5. The first version of the interface is nearly ready to be reviewed by a human developer: the work will be continued in sprint #6.

Move from patched “perf” to in-house equivalent

Due to two extra tasks having to be urgently tackled first (see the sections above), no time was left to address the overhaul of the patched-“perf” arrangement in the linuxperf Adaptyst module. This is still of high priority though and will form part of the sprint #6 plan.

Next sprint

Sprint #6 will start shortly after the publication of this post (i.e. on 13 August 2026) and will last until Wednesday 26 August 2026 at noon CERN time. It can be followed via the usual channels.