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

[Martin]

Martin wrote:
> 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.

I had that right,, just the debugger confused me the way it displayed 
the values.

Attached patch works here, and dumps 15 frames in between 1 and 2 secs.

>
> 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] ?
>
> Martin
>
>
> Martin wrote:
>> 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
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel

-------------- 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/cc892b44/attachment.ksh>