Skip to content

Function Sub-Node Units & Impact Ranking

File Reference: gitgalaxy/metrics/signal_processor.py

Engineering Summary

An extraction and ranking system surfaces individual function declarations to render them as child entities orbiting parent files. It solves the problem of hidden internal complexity within large monolithic files by exposing internal modularity. This subsystem provides a visual inventory of discrete logic blocks directly in the 3D environment, acting as the function sub-node system in GitGalaxy.

Purpose

To display the internal structure and modularity of files by rendering high-impact functions as distinct geometric entities.

Problem Being Solved

A large file node does not reveal whether the file contains one monolithic 2,000-line function or a well-structured set of 100 small utility methods. Rendering functions as sub-nodes exposes this internal architecture.

Design

Functions are ranked by an Impact Score: $\(Impact Score = ((BranchHits + 1) \times (Args + 1) + (0.05 \times LOC)) \times 10\)$ To prevent visual clutter, only the top 12 highest-impact functions per file are rendered. Default rendering properties include low-polygon spherical meshes, inherited parent node colors, and uniform angular velocity for orbital paths.

Pipeline Integration

  • Inputs: Function metadata (LOC, branches, arguments) generated by the extraction parser.
  • Outputs: Renderable sub-node arrays limited to the top 12 functions per file.
  • Dependencies: Consumes parsed block metrics; outputs to the orbital rendering logic in the UI. 
    Extracted Function Blocks -> Impact Ranking and Capping -> Renderable Child Entities

Tradeoffs

Capping the display at 12 functions truncates the complete structural view of highly modular files. This limitation guarantees that the GPU vertex count remains manageable and ensures orbital paths do not overlap chaotically.

Limitations

  • Functions below the top-12 impact threshold are completely hidden from the 3D visualization.
  • Does not distinguish between private internal helpers and public API methods.

Performance Notes

Limiting sub-nodes strictly binds the maximum possible vertex count per file, providing predictable \(O(1)\) upper-bound rendering performance regardless of actual file complexity.

Future Work

  • Implement clustering algorithms to group minor functions into aggregate sub-nodes instead of dropping them.
  • Differentiate public vs. private methods using distinct sub-node shapes or colors.