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

[Martin]

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] ?

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