From b18d81cbbec168a21b85e67eab3b5fc2a8d4de26 Mon Sep 17 00:00:00 2001 From: Bartosz Taudul Date: Sun, 17 May 2026 14:08:54 +0200 Subject: [PATCH] Explicitly state which code paths are important to consider. --- profiler/src/llm/skill.optimization.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/profiler/src/llm/skill.optimization.md b/profiler/src/llm/skill.optimization.md index 390f536e..0bdb08da 100644 --- a/profiler/src/llm/skill.optimization.md +++ b/profiler/src/llm/skill.optimization.md @@ -49,6 +49,10 @@ Analyzing a user program can be done in two complementary ways. 1. You can retrieve the function source code and look at what it does. This is enough for simple checks. 2. Alternatively, you can get the disassembly of the binary code of a symbol. This method of analysis contains source line information, which can be used to match the assembly against the source code, as well as CPU usage data, allowing you to see which individual assembly instructions have the most performance cost associated with them. Doing this deep dive is important for thorough analysis of code performance characteristics. +# Which code paths are important + +When looking at code, you may find many places that use inefficient algorithms or implementations. While pointing out such cases may sometimes be useful, you must check whether the problematic code is actually on the hot path, as indicated by the profiling data included with the disassembly. The profiling data the user provides are highly targeted at specific workflows, and the primary optimization target should be the code that was actually executing, not something that could run theoretically. Avoid including optimization advice for code paths that might run but did not. + # General optimization procedure 1. Start by mapping the assembly instructions to the source code. All reasoning should be performed with source code first. The assembly can only be used as a supplementary source.