Show HN: GalataJ – Runtime-aware Java profiling inside IntelliJ and VS Code
1 comments
Under the hood it uses runtime bytecode instrumentation with dynamic attach to avoid restarts.
The main trade-off was balancing per-method granularity with minimal overhead. I chose to surface execution time, call count, and allocations since those tend to answer most “what should I optimize?” questions during development.
Curious what metrics others find most useful in day-to-day profiling.
The main trade-off was balancing per-method granularity with minimal overhead. I chose to surface execution time, call count, and allocations since those tend to answer most “what should I optimize?” questions during development.
Curious what metrics others find most useful in day-to-day profiling.
While working on large Java projects, I often found myself digging through heap dumps and flame graphs just to answer a simple question:
Which methods are actually slow, and how much do they cost?
Traditional profilers are powerful, but interpreting the output takes time. AI tools can read source code — but they don’t see what happens at runtime.
So I built GalataJ.
GalataJ is a lightweight Java profiler that works directly inside IntelliJ (including Community Edition) and VS Code. The workflow is simple: Profile → Compare → Act, without leaving the editor.
Profile Bytecode instrumentation attaches to a running JVM (no restart required). It collects per-method execution time, call count, and memory allocation. Metrics appear directly in the editor as CodeLens hints above your methods.
Compare You can save profiling sessions and define baselines. If a method becomes 30% slower compared to a previous run, you see it immediately — no dashboards or flame graph interpretation required.
Act Profiling results are exported as structured Markdown files inside the project (.galataj/). They are: * Plain text * Version-controllable * Tool-agnostic There’s also an “Add to Chat” action that sends the structured runtime data directly to the IDE’s built-in AI assistant. Instead of describing a performance issue manually, you can provide actual execution metrics and let the AI reason with real runtime context. The goal isn’t automation — it’s giving better inputs.
What it is not: * Not an APM * No distributed tracing * No production monitoring * No automatic deadlock detection It focuses on one thing: Helping developers understand runtime bottlenecks during development.
Would appreciate feedback from JVM and performance folks. Happy to answer questions about the instrumentation approach or overhead trade-offs.
website : www.galataj.com