| Age | Commit message (Collapse) | Author | |
|---|---|---|---|
| 2026-03-26 | Rewrite GNU3 demangler for performance using DemangledTypeNode | Peter LaFosse | |
| 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> | |||
| 2026-01-01 | update copyrights for 2026 | Jordan Wiens | |
| 2025-03-28 | missed the older dates! | Jordan Wiens | |
| 2024-10-23 | Compile demangler plugins directly into the core for P E R F | Glenn Smith | |
| 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. | |||
| 2024-10-17 | Demangler plugin API | Glenn Smith | |
| Closes #467 | |||
 |
index : public/binaryninja-api.git | |
| [no description] |
| summaryrefslogtreecommitdiff |