4 ms·
Whatever information is within the line number information - it can stored in a simple, naive way - and then compressed normally. There is absolutely no justif
by Peaker 9y ago
Whatever information is within the line number information - it can stored in a simple, naive way - and then compressed normally.
There is absolutely no justification in inventing a virtual machine with its own opcodes for this.
- the_mitsuhiko 9y ago>Whatever information is within the line number information - it can stored in a simple, naive way - and then compressed normally. Not sure how a compression is going to be better than a VM. The "vm" here is super simple and achieves significantly better compression than an actual compression algorithm. And it's easier to implement and work with. Also again this is not just line information so you really want a state machine for this or this explodes in more and more complexity. We built a system that generates out simple mappings from DWARF's line number programs to files we can mmap and it's only smaller for the case we are about (line number info). Anything else and DWARF's programs are better. So no surprised DWARF works the way it does.
- Peaker 9y agoWhen you just want line number info from DWARF -- all the existing tools are extremely slow. A simple sorted address->line table with binary search is incredibly faster. This is a very common use case. At the very least, this proves DWARF is not designed for its common use cases, not properly at least.
- the_mitsuhiko 9y ago> When you just want line number info from DWARF -- all the existing tools are extremely slow. Sure, but so are sourcemaps. If that is all the info you need then you can build tables for that which is as mentioned precisely what we do. However DWARF is more than that and DWARF is a really good standard for debug information data. You can trivially build cache files for the subset of info you need out of them.