argh [Re: [fpc-devel] time for dumping stacktrace, when using dwarf.]
lazarus at mfriebe.de
Sat Nov 14 04:09:10 CET 2009
I'll have to withdraw it.
I have no idea how I compiled an exe that actually did not crash when
dumping a stack (yes I had one.). but the patch doesn't work.
Problem I have is how to deal with the open var param.
I need to be able to address the first (or other) byte of it
function ReadNext(var dest; size : SizeInt) : Boolean; inline;
how to I get dest[n] ?
> Michael Van Canneyt wrote:
>> On Tue, 10 Nov 2009, Schatzl Thomas wrote:
>>> The main reason for this slowness is that that implementation (of
>>> mine) reads debug info byte-by-byte from the input stream using
>>> blockread(). I think this I/O the main performance bottleneck.
>>> At that time I did not bother improving this since it is sufficient
>>> for my purposes. I did not test with very large debug infos because
>>> on my development platform Lazarus does not work >:)
>>> Improving upon that should be trivial, all reading from the debug
>>> input has been encapsuled in the two ReadNext() methods in the file
>>> mentioned. It should be easy to make them to read from a (static?)
>>> buffer that is filled blockwise; note that a static buffer may give
>>> headaches for MT programs, and you are strongly discouraged to do
>>> memory allocation during crashes...
>> By making the buffer a threadvar, this should not be an issue ?
>> I was glad to read your answer, because I was having the same problem
>> as Martin.
>> I ended up by simply disabling the stack trace.
> Ok , I have created a patch. And it does the trick. Without it dumping
> about 15 frames took 30secs. With the patch it stays below 1 sec (too
> fast to measure).
> The patch only uses a buffer of 100 bytes. I think this should not be
> a problem in terms of resource usage. (They are allocated as const
> buf: array [0..99] of byte)
> About thread save.
> The code already was not thread save, because the variable "e" Which
> contains the file handle etc, is a normal global variable (Apparently
> in order to be able to close it in the units finalisation).
> Of course normally that doesn't mean to add to the fault. Yet for now
> I have allocated the buffer as global var too.
> There are 2 ways to make it thread save:
> 1) Make e and buf threadvar
> It will still only be 100 bytes per thread (probably it would even be
> fine with 50 bytes per thread), so the memory usage would still not be
> too bad.
> 2) Protect "GetLineInfo" with a spin lock
> That is probably preferable anyway
> Otherwise, I have no idea about the coding style used in fpc. So sorry
> if my patch does not follow it.
> Also I made 2 procedures "inline", I have not tested how much time
> that gains, but I guess it is minor. So if that isn't compliant with
> the code guidelines, remove it
> fpc-devel maillist - fpc-devel at lists.freepascal.org
More information about the fpc-devel