search

pbrisbin / bugsnag-haskell

Bugsnag error reporter for Haskell
10 stars 7 forks source link

Warn of compile time impact of buildCodeIndex #59

Closed MaxGabriel closed 4 years ago

MaxGabriel commented 4 years ago

I noticed this was getting pretty slow for us at work, and I figured I should warn others about it. For us, it was embedding something like 145K lines in a single file! I used -ddump-splices -ddump-to-file to see the generated code.

pbrisbin commented 4 years ago

I'm so pumped you use this feature! How's it working out? Does it result in nice stack traces in Bugsnag? I'd love to see some screenshots. It definitely seems untenable at scale, which is why I myself don't even use it. I swear I had this warning (or one like it) somewhere at some time. Anyway thanks for (re-)adding it!

Also open to suggestions for making it behave better. Perhaps a safelist/blocklist of source to index (or not), so you can choose to accept the burden only for files that you think could appear in stack traces? Maybe we could figure out where the HasCallstacks are and only index files that contain that. :thinking:

MaxGabriel commented 4 years ago

Ah, so unfortunately I'm not sure it is working out :( I think our production environment doesn't ever have stacktraces, so I don't know that I've seen this working, but I'm not certain. I had some vague notion that in Haskell you would only get stacktraces if you compiled with a certain flag on?

Here's an exception I triggered manually that used error, without a stacktrace (besides the line error was called on):

image

Also open to suggestions for making it behave better.

One thing that might help is a way to merge code indexes together. Something I've found is that GHC is really hampered by doing parallelism at the module level, so if you had say 8 modules each doing some portion of the codebase, then a master module combining them together (or something like that—the code search stuff could take a list of code indexes maybe too), I expect that would be way faster.