[fpc-devel] time for dumping stacktrace, when using dwarf.

[Martin]

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

Martin

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fpc_dwarf_buffer.patch
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20091114/f37cd7a0/attachment.ksh>