| Age | Commit message (Collapse) | Author |
|---|
|
Replace the TypeBuilder-based demangling path with a lightweight
DemangledTypeNode representation that defers type object construction
until the symbol is fully parsed. This avoids repeated heap allocation
and ref-count churn during recursive descent.
Key changes:
- Add DemangledTypeNode / demangled_type_node.{h,cpp}: a compact IR
that mirrors the type grammar without allocating BN Type objects
- Use a thread_local demangler instance to amortize vector allocations
across calls
- Also commonize some of the demangled string length calculations.
Result: ~3x throughput improvement on a 180K-symbol corpus with
97.7% success rate (matching the previous implementation).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
|
|
|
|
cause bugs and also issues with C++20
|
|
Fixes https://github.com/Vector35/binaryninja-api/issues/6902 however we still need to figure out what we want to do about the type info names being invalid. There really is not a good way to tell without saying all type info names _must_ be mangled.
|
|
|
|
Fixes #6261
|
|
|
|
Turns out, this is a rather hot path on initial binary loading (>50% runtime), and trying to pipe it all through the FFI makes it really slow. Like 100% slower. Ouch. Now, the demangler plugins are written with a bunch of #ifdef macros to allow for building both as a plugin and directly into the core. There is no functionality change here apart from regaining the lost performance.
|
|
Closes #467
|
