> The approach we're using here is parsing the minified JavaScript source from the error location backwards in WTF-16 units, then compare that to the token we see in the unminified source and doing a reverse lookup
What if instead of that you’d actually compile all JS files once to some sensible format that would allow you to do lookup of variable in any scope?
Then you only need token to token map to find the proper location in your precimpiled data.
> However we're different. We're not handling a single app, we're handling tens of thousands of customers and their apps and websites. We can't just have all the debug info files resident at all times, they are too many. Likewise the events we get constantly are from vastly different versions. I don't have numbers right now but I guess we store terrabytes of debug data we use for processing.
So how much do you have of it?
All in all, precomputing space-efficient index and storing it in some memcached-style solution should deal with that. I bet you don’t need full debug info as in complete DWARF data.
> Ops can better attest to that but we're not huge fans of depending too much on pinning customers to single workers.
Shards can be rebalanced. Also a memcached or whatever DHTs can used to keep shards. This way workers stay uniform but lookups are still fast.
> What if instead of that you’d actually compile all JS files once to some sensible format that would allow you to do lookup of variable in any scope?
An enormous amount of javascript and sourcemaps we are dealing with are one hit wonders and/or need fetching from external sources. We have no impact on the format of the data there and as mentioned converting it once into a different format does not at all help here.
> I bet you don’t need full debug info as in complete DWARF data.
Correct, which is why as part of making processing of iOS symbols faster we wrote our own file format that we can efficiently mmap. It's 10% of the size of the average DWARF, gives us all the information we want without parsing or complex processing (https://github.com/getsentry/symbolic/tree/master/symcache).
The reason I'm writing this is because as you can see we're very far away from "just handling boring events". There is a ton of complexity that goes into it. We're not idiots here ;)
> Shards can be rebalanced.
That changes nothing about the fact, that unless we have to introduce any form of affinity we are better off writing faster code that does not depend on it.
> Correct, which is why as part of making processing of iOS symbols faster we wrote our own file format that we can efficiently mmap. It's 10% of the size of the average DWARF, gives us all the information we want without parsing or complex processing
Exactly, cool that you do it.
> enormous amount of javascript and sourcemaps we are dealing with are one hit wonders and/or need fetching from external sources.
Hm, so you don’t know what code your customers deploy?
At least in JS you seem to imply that.
Anyhow pardon me for beeing rude in my early posts.
It’s exciting things you do and I’d love discuss on some other medium. How can I reach you?
What if instead of that you’d actually compile all JS files once to some sensible format that would allow you to do lookup of variable in any scope?
Then you only need token to token map to find the proper location in your precimpiled data.
> However we're different. We're not handling a single app, we're handling tens of thousands of customers and their apps and websites. We can't just have all the debug info files resident at all times, they are too many. Likewise the events we get constantly are from vastly different versions. I don't have numbers right now but I guess we store terrabytes of debug data we use for processing.
So how much do you have of it? All in all, precomputing space-efficient index and storing it in some memcached-style solution should deal with that. I bet you don’t need full debug info as in complete DWARF data.
> Ops can better attest to that but we're not huge fans of depending too much on pinning customers to single workers.
Shards can be rebalanced. Also a memcached or whatever DHTs can used to keep shards. This way workers stay uniform but lookups are still fast.