https://d.puremagic.com/issues/show_bug.cgi?id=9584
--- Comment #20 from Adam D. Ruppe <destructiona...@gmail.com> 2014-02-07 20:10:53 PST --- My pull request there is posix only. A win but not complete without looking at Windows too. And I'm not sure I understand the Windows stack trace code. There must be something lazy initialized in there since the first exception handled is significantly slower than any subsequent ones, with or without the trace handler. At first I thought it was loading the debug help library, but that seems to be done in a static module constructor. Maybe it is deferred anyway, idk. But anywho with the trace handler turned on, the second exception clocks in at about 250 us. With the trace handler turned off, the second exception comes in at about 30, same ballpark as linux after the change. So we are still looking at a huge potential improvement here. But I'm not sure where and my windows dev environment sucks. Maybe we can move the call to m_trace = trace out, into opApply too, just storing the CONTEXT*. Could work, but then again, the trace method says it returns a thing to be used by resolve later on, so maybe it is important to be done here. idk, gotta experiment with it and I'm out of time tonight. At least the Linux change seems to be a big success so far. BTW I can't help but wonder if we can't shave a few more useconds off by getting the trace info objects from a small reusable pool instead of doing `new` each time we throw an exception. I think we should get a small, cost-free (from the user perspective) win there too. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
