gigiProfiler: Profiling App-Level Contention

• gigiProfiler is a specialized profiler that diagnoses performance problems caused by application-defined resource contention rather than conventional CPU hotspots.
• It employs a hybrid LLM-static analysis pipeline to identify, instrument, and trace both exclusive and shared resources for precise bottleneck localization.
• Empirical evaluations on systems like MySQL and Apache demonstrate its effectiveness in uncovering performance issues that traditional profilers often miss.

Searching arXiv for the cited papers to ground the article in current records. gigiProfiler is a profiler designed specifically to diagnose performance problems whose root cause is contention or waiting on application-level resources, not just slow code paths or OS-visible waits. Introduced as a realization of OmniResource Profiling, it integrates system-level and application-level resource tracing, uses a hybrid LLM-static analysis approach to identify application-defined resources offline, and analyzes their impact on performance during buggy executions to uncover the performance bottleneck; it then samples and records critical variables related to these bottleneck resources during buggy execution and compares their value with those from normal executions to identify the root causes (Hu et al., 8 Jul 2025). In adjacent 2024 work, the label “gigiProfiler” is also used only as a framing device for a guided personal-profile generation layer over LLM personalization (Zhang, 2024) and for a graph-profiling tool built around Graph Generating Dependencies (Shimomura et al., 2024).

1. Problem domain and target bottlenecks

The 2025 system targets performance issues in which the decisive bottleneck is an application-defined resource with a custom resource management policy rather than a kernel-visible wait primitive. Traditional profilers such as perf, gprof, off-CPU profilers like wPerf, and system tracers largely focus on CPU time, hot functions, cache misses, OS-level blocking, and causality between kernel events or RPCs. They fail when the application uses its own resource abstractions, such as undo logs, buffer pools, metadata locks, queues, or thread pools, implemented purely in user space, and when waiting is done by custom logic such as spinning, polling on flags, or custom wait queues rather than OS primitives (Hu et al., 8 Jul 2025).

The motivating examples emphasize this distinction. In the MySQL UNDO log contention case, transactions block not on a POSIX mutex but on application logic tied to node->index; the purge thread scans a long linked list in trx_undo_prev_version_build, holding a latch for tens of milliseconds, while other threads spin or yield in user code. In the dirty buffer example, one thread periodically checks is_dirty on a buffer and yields while another cleans it; there is no lock or blocking syscall, so the wait is purely in application logic. A common misconception is therefore that gigiProfiler is a conventional CPU or off-CPU profiler. The system is instead built for cases where the key questions are which resource is contended, who is holding it, who is waiting, and why (Hu et al., 8 Jul 2025).

The evaluated resource classes include UNDO log, buffer pool pages, metadata locks, table metadata, foreign key structures, MariaDB concurrency queues (srv_thread_concurrency), PostgreSQL MultiXact cache and pg_stat_statements hash, Apache TCP send buffer and worker thread pools, and LLAMA result queues. These examples define the intended scope: mature systems in which performance regressions are often explained more accurately by resource contention semantics than by CPU hotness alone (Hu et al., 8 Jul 2025).

2. OmniResource Profiling and the resource model

The central abstraction is OmniResource Profiling, defined as tracing and analyzing all resources relevant to performance, both system-level and application-defined resources, in a unified manner. Instead of restricting “resource” to objects the operating system explicitly understands, the framework generalizes the term to include exclusive resources, accessible by only one thread at a time, and shared resources, concurrently accessed with contention reflected in different performance across paths (Hu et al., 8 Jul 2025).

In the model codified in Algorithm 1, each resource res has res.type ∈ {exclusive, shared} and a set of operator functions. For exclusive resources, operator functions acquire, hold, or release the resource; for shared resources, operator functions access the resource or cause contention on it. During profiling, gigiProfiler maintains res_usage[res], res_block[res], and, for each resource-holder thread, res_block[res] [thread]. The bottleneck resource is selected by a blocking-time ranking:

$$\text{bottleneck} = \arg\max_{res} \; res\_block[res]$$

and the worst contributor thread is selected as

$$\text{longest\_holder} = \arg\max_{\text{thread}} \; res\_block[\text{bottleneck}][\text{thread}].$$

This ranking is deliberately simple: the paper does not introduce a more complex statistical model, and the analytical core is blocking time attribution by resource and holder thread (Hu et al., 8 Jul 2025).

This resource model is what separates the system from standard execution profilers. For exclusive resources, blocking is measured when a thread tries to access the resource and cannot, including custom wait loops. For shared resources, contention time measures how long a thread’s access is slowed due to resource pressure, while hold amount captures how long another thread keeps the resource in a state that slows others. The result is a unified ranking in which application-defined constructs appear in the same analysis pipeline as system resources, rather than remaining invisible behind generic CPU or scheduler symptoms (Hu et al., 8 Jul 2025).

3. Hybrid LLM–static analysis and tracing pipeline

The architecture has three phases: offline hybrid analysis, online profiling of buggy execution, and root cause analysis via value-assisted profiling. In the offline phase, the input is documentation, comments, and source code, and the output is a list of application-defined resources and operator functions categorized as exclusive or shared. In the online phase, the application is rebuilt or launched with instrumentation, and gigiProfiler records resource usage and blocking times for identified resources and threads, producing a buggy profile. In the final phase, the tool selects critical variables, re-runs buggy and normal executions, and compares sampled values and loop execution behavior to produce a report containing bottleneck resources, critical operator functions, and key variables and code locations whose values or behavior differ between buggy and normal runs (Hu et al., 8 Jul 2025).

The resource-discovery stage uses a hybrid LLM–static analysis approach because neither pure static analysis nor pure LLM inference is sufficient. Pure static analysis cannot easily recognize application-specific concepts such as UNDO log, buffer pool, or pgss hash, and pure LLM prompting is vulnerable to missing context, misleading comments, comment loss, and probabilistic inconsistency. The hybrid decomposition assigns coverage to the LLM and validation to static analysis (Hu et al., 8 Jul 2025).

Before prompting, the tool constructs a hierarchical metadata tree for the codebase. The root is a file node with filename and file-level description; child nodes represent classes, functions, and global variables; each node stores structured metadata such as description, signature, parameters, return type, and variable type. The LLM is then guided with chain-of-thought prompts. At the file level, it decides whether a file is likely to contain resource definitions or key operations and can emit NEED_DEF when uncertain. At class and function level, prompts ask whether a class or function defines or manipulates a resource, whether the resource is exclusive or shared, and whether more context is needed. This yields candidate resources and candidate operator functions (Hu et al., 8 Jul 2025).

Static validation filters false positives with code-pattern analysis. For exclusive resources, the validator searches operator functions for synchronization primitives that cause yielding, including system calls, inline assembly, or primitives that yield the thread, and then performs data-flow analysis to ensure the variables used in those primitives are actually part of the resource object. For shared resources, it looks for control-flow variables in operator functions that lead to divergent behavior and checks whether those variables interact with the resource, or alternatively checks interaction with system resources via a whitelist relevant to the resource type. Because the LLM narrows the candidate set first, the static analysis can afford deep inter-procedural data-flow analysis without scalability collapse (Hu et al., 8 Jul 2025).

Once resources and operators are validated, gigiProfiler instruments the application binary. For exclusive resources it instruments entry and exit of resource usage functions to timestamp acquisition and release and to record blocked intervals. For shared resources it instruments synchronization primitives at resource usage points to capture acquisition and release times and to identify contention. Metrics are recorded in thread-local memory, and a background profiler thread periodically aggregates local metrics into global res_usage and res_block maps. For system-level data, the tool integrates with Linux perf and off-CPU techniques to periodically sample call stacks and kernel events (Hu et al., 8 Jul 2025).

4. Bottleneck localization and value-assisted root cause analysis

The online diagnosis assumes a buggy execution that exhibits performance degradation and, for comparison-based root cause analysis, a normal execution with the same code and environment but different configuration or workload that does not show the degradation. During the buggy run, the profiler collects T_hold(res, thread) and T_blocked(res, thread) for exclusive resources, and T_contention(res, thread) and T_hold(res, thread) for shared resources. These measurements are then aggregated into per-resource blocking and usage metrics, and the top-ranked resource is reported together with the longest holder and its operator functions (Hu et al., 8 Jul 2025).

The second analytical step addresses the question of why the bottleneck resource is under abnormal pressure. Recording all variables is infeasible, so the tool uses static analysis to identify value-critical variables tied to resource usage. It inspects loops in operator functions and their callers, extracts loop exit conditions, and selects variables such as pointer traversals, configuration limits, or flags that directly influence how long a resource is held or how often it is exercised. The paper’s examples include undo_rec in MySQL undo-log traversal, srv_thread_concurrency in MariaDB, and event_conn_state_t in Apache (Hu et al., 8 Jul 2025).

Sampling is then restricted to the loops and variables in operator functions of the identified bottleneck resources. At loop entry or exit, or at sampling points inside the loop, the profiler logs iteration count, execution time, values of exit-condition variables, and possibly per-iteration delay patterns. It performs the same selective sampling in the normal run and compares distributions and magnitudes. The paper does not define a formal statistical test; the conceptual criterion is whether loop iterations or variable values are significantly larger or otherwise systematically different in the buggy run than in the normal run (Hu et al., 8 Jul 2025).

The published case studies illustrate the method. In the MySQL UNDO log case, the bottleneck resource is node->index, the key functions are trx_undo_prev_version_build and row_vers_old_has_index_entry, and the critical variable is undo_rec; the buggy run scans many more undo records, so the purge thread holds the resource while scanning and other threads block. In MariaDB MDEV-24759, the resource is the queue controlling concurrency, the operator function is innobase_srv_conc_enter_innodb, and the critical variable is srv_thread_concurrency; the diagnosis is a misconfigured concurrency limit. In Apache-60956, the bottleneck resource is the TCP buffer, the key function is start_lingering_close_nonblocking, and the critical variable is event_conn_state_t; the buggy clients stop receiving, so connections remain in a state waiting for buffer space much longer than in normal runs (Hu et al., 8 Jul 2025).

5. Empirical results, overhead, and comparison with traditional profilers

The evaluation covers 12 real-world performance issues across five applications: MySQL, MariaDB, PostgreSQL, Apache HTTPD, and LLAMA (llama.cpp). The hardware platform is a 10-core Intel Xeon E5-2640 @ 2.4 GHz with 64 GB DRAM, 480 GB SSD, and Ubuntu 20.04. The issues include UNDO log contention, metadata lock conflicts, buffer pool pressure, thread and queue contention, PostgreSQL cache and hash contention, network buffer and thread pool contention in Apache, result queue contention in LLAMA, and two unresolved MariaDB regressions, MDEV-34989 and MDEV-34836 (Hu et al., 8 Jul 2025).

The core quantitative results are summarized below.

Metric	Result	Context
Bottleneck identification	all cases	12 real-world performance issues
True root cause ranked top	9/12 cases	other 3 had multiple root causes
Average analysis time	95.15 seconds	none exceeding ~3 minutes
Average runtime overhead	5.86%	six evaluated cases
Exclusive resource identification accuracy in MySQL	80.4%	hybrid LLM + static validation

The comparison with perf is central to the paper’s argument. In 7 of 12 cases, perf never reports the root cause function in its profiles. In the remaining 5 cases, the root cause is rarely among the top 5 functions and can appear far down the list, including ranks 68 and 51 for buffer pool functions. The reason given is that many problematic threads are waiting rather than burning CPU, and perf cannot connect blocked state to application-level resource semantics. gigiProfiler, by contrast, attributes blocked or contended time directly to the resource and operator function, independent of CPU usage (Hu et al., 8 Jul 2025).

The evaluation also isolates the value of the hybrid analyzer. For exclusive resources in MySQL, a static-only approach found 49 resources with 41.9% accuracy, an LLM-only approach found more than 2000 resources with 3.7% accuracy, and the hybrid approach produced a final resource list of 92 with 80.4% accuracy. This directly supports the paper’s design claim that LLMs provide coverage while static analysis provides precision (Hu et al., 8 Jul 2025).

Two previously unresolved MariaDB issues serve as diagnostic case studies rather than benchmark-style replications. For MDEV-34989, the tool traced blocking to TABLE_SHARE, identified a line in vector_mhnsw.cc where an insert thread waits indefinitely, and found a path in mhnsw_first where the table is not released if empty; developers confirmed the diagnosis and fixed the bug. For MDEV-34836, it identified a DDL transaction on a parent table being blocked because Galera’s Total Order Isolation fails to abort conflicting DML on a child table and traced the issue to TOI mechanism and lock-handling logic (Hu et al., 8 Jul 2025).

6. Related uses of the name and broader profiling interpretations

The named system in the 2025 literature is the application-resource bottleneck profiler. Two 2024 papers, however, explicitly frame different architectures as “gigiProfiler” or as a “gigiProfiler-like tool,” and these uses are conceptually related only at the level of intermediate profiling and summarization rather than implementation or domain (Zhang, 2024, Shimomura et al., 2024).

In “Guided Profile Generation Improves Personalization with LLMs” (Zhang, 2024), “gigiProfiler” is described as an engineering implementation of Guided Profile Generation: a reusable microservice that takes raw user history and context, generates a compact natural-language profile via guided prompts, and serves that profile to downstream LLM apps for personalization. The underlying pipeline is a multi-call prompting architecture with context digestion, guided profile generation, and downstream response generation. The paper reports that on Amazon purchase preference prediction, GPG increases accuracy from 47.55% for direct generation with raw personal context to 65.08%, described in the abstract as a 37% accuracy increase compared to directly feeding raw personal context (Zhang, 2024).

In “Discovering Graph Generating Dependencies for Property Graph Profiling” (Shimomura et al., 2024), the phrase “for a gigiProfiler-type tool” refers to a graph profiler built on Graph Generating Dependencies discovered by GGDMiner. That framework has three main steps—pre-processing, candidate generation, and GGD extraction—and uses a factorized representation of each discovered graph pattern called Answer Graph. Its output is a set of approximate Extension GGDs that can give an overview about the input graph, both schema level information and also correlations between the graph patterns and attributes (Shimomura et al., 2024).

A plausible implication is that “gigiProfiler” names a broader design pattern in which a system inserts an explicit profiling layer between raw signals and downstream diagnosis or decision-making. In the 2025 profiler, the layer extracts resources, operator functions, and value-critical variables from source code and executions. In the 2024 personalization framing, the layer converts raw personal context into concise natural-language profiles. In the 2024 graph-profiling framing, the layer converts a property graph into declarative Graph Generating Dependencies. The shared idea is not a common implementation, but the use of intermediate profiles to expose otherwise latent structure (Hu et al., 8 Jul 2025, Zhang, 2024, Shimomura et al., 2024).