Long delay before callback gets called after StackTrace.fromError()

[sebastientromp]

Hello,

I've noticed that there is a significant delay for resolving the callback, about 15-70s between the time I do the call to StackTrace.fromError and the time the callback actually gets called.

I have an angular project, and to reproduce the issue I simply add the following line when booting up the app:

console.log('calling fromError');
StackTrace.fromError(new Error(), { sourceCache : {}}).then(function() { console.log('first source map done')});

results in

2017-04-26 10:09:39.989  calling fromError
2017-04-26 10:09:55.197  first source map done

Looking at what happens in the Chrome's Network tab, it looks like only one call to getting the sourceMaps is done (though subsequent calls to fromError will generate more requests to get the sourceMaps, they are taken from the cache so it doesn't seem to be an issue, and at least not relevant to the one at hand here).

Removing the source maps from the compilation solves the issue (less than 1s delay), so it seems to be linked with sourcemap loading or resolving.

I'm testing in local, so downloading the ~2-4MB sourcemaps is fast (and I also reproduce the latency when getting the sourcemaps from cache), so I assume it's the parsing that takes time.

Is there anything you know I could do to speed up this process? I'm using stacktrace parsing to send notifications on Slack when something goes wrong, and I'm worried the user might close the window before the full processing is done if it takes too long.

Thanks for your help!

Sébastien

[eriwen]

@sebastientromp consuming the source map is expensive, and I have implemented caching best I can think of to make it fast. If performance is an issue, I recommend using error-stack-parser by itself. If you need source maps, you might consider a process that reports stacktraces for unmapped sources to your server, and then a separate process to get the source map and map the stack traces to the original. This is something I hope to make easier in the next couple releases of stacktrace.js with #173

[sebastientromp]

@eriwen That's a really good idea, and would fit my need perfectly. There is for now no urgency, but I'll have a look when I have time.
Just out of curiosity, are there specific tests for performance? Would you be open to PR that tests this?

Thanks again for all the work, it's a pretty awesome tool you're building here.

[eriwen]

Yes, I'd love a PR with perf tests. Thanks!

…

On Wed, Apr 26, 2017 at 10:45 PM Sébastien Tromp ***@***.***> wrote: @eriwen <https://github.com/eriwen> That's a really good idea, and would fit my need perfectly. There is for now no urgency, but I'll have a look when I have time. Just out of curiosity, are there specific tests for performance? Would you be open to PR that tests this? Thanks again for all the work, it's a pretty awesome tool you're building here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#189 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADJTu7rejLew-pud5B-DFY8kUfjJ-Rlks5r0CtdgaJpZM4NIhSn> .

[jogjayr]

@eriwen I'm encountering this issue also. My understanding is that since the sourcemap parsing is on the main thread the UI freezes up completely while it happens.

I don't understand this all that well, but I wonder if here:

get: function StackTrace$$get(opts) {
    var err = _generateError();
    return _isShapedLikeParsableError(err) ? this.fromError(err, opts) : this.generateArtificially(opts);
},

it might help improve performance if this.fromError were run in a Web Worker? I am willing to give it a try and report back (with PR) if you think it's a promising direction to go in.

[eriwen]

@jogjayr I think that's a good idea, but we must do it in a backward-compatible way.

I'm happy to consider a PR with this, with bonus points if you can do some performance analysis that proves it's effectiveness.

[jogjayr]

@eriwen As a PoC I tried calling StackTrace.get inside of a WebWorker. It doesn't get the correct call stack. Rather than showing the call stack with the stack top being the line where the error originated, it gets the WebWorker's own call stack. I guess that makes sense; the call to the Web Worker isn't part of the same call stack where the error originated. Are you sure there's a way to use Web Workers to solve this issue?

[odusseys]

I'd like to notify that we are running into the same problem with disastrous results. Calls to _parseMappings are making the entire UI freeze for upwards of 8 seconds in severe cases. We have been forced to remove stacktracejs as a consequence.

[rquast]

Great library but experienced the same issues with the UI freezing. Wouldn't mind a webworker solution if anyone can figure it out.