You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 6302 Reporter:@alainfrisch Assigned to:@jhjourdan Status: closed (set by @xavierleroy on 2015-12-11T18:26:51Z) Resolution: fixed Priority: normal Severity: minor Fixed in version: 4.02.0+dev Category: runtime system and C interface Related to:#5899 Monitored by:@gasche@jmeber@yakobowski
Bug description
The function read_debug_info() in byterun/backtrace.c is called every time a backtrace is requested.
Recently, we wanted to log backtraces in one piece of the program and it became extremely slow in bytecode. The .cds file has about 40Mb, and it takes about 0.5s to read it.
What's the rationale for re-reading debug infos every time instead of keeping it in memory?
If it's considered problematic to keep the data in RAM (esp. considering it can be so large), we could have at least have an option to do so, or maybe consider using a more compact representation for location information required for backtraces. Currently, we use debug events, which are much richer than what we need (only their ev_pos and ev_loc fields). We could project debug events to these two fields either upon reading the debugging info in backtrace.c, or maybe have this more compact data stored as a different section in the bytecode/.cds file to optimize reading it.
The text was updated successfully, but these errors were encountered:
Indeed, I think keeping only the ev_pos and ev_loc of the "events" structure and keeping that in memory should be unproblematic. I had never noticed that event_for_location does a linear search in the event list, do you think that could also be a performance issue for backtrace-heavy applications?
Original bug ID: 6302
Reporter: @alainfrisch
Assigned to: @jhjourdan
Status: closed (set by @xavierleroy on 2015-12-11T18:26:51Z)
Resolution: fixed
Priority: normal
Severity: minor
Fixed in version: 4.02.0+dev
Category: runtime system and C interface
Related to: #5899
Monitored by: @gasche @jmeber @yakobowski
Bug description
The function read_debug_info() in byterun/backtrace.c is called every time a backtrace is requested.
Recently, we wanted to log backtraces in one piece of the program and it became extremely slow in bytecode. The .cds file has about 40Mb, and it takes about 0.5s to read it.
What's the rationale for re-reading debug infos every time instead of keeping it in memory?
If it's considered problematic to keep the data in RAM (esp. considering it can be so large), we could have at least have an option to do so, or maybe consider using a more compact representation for location information required for backtraces. Currently, we use debug events, which are much richer than what we need (only their ev_pos and ev_loc fields). We could project debug events to these two fields either upon reading the debugging info in backtrace.c, or maybe have this more compact data stored as a different section in the bytecode/.cds file to optimize reading it.
The text was updated successfully, but these errors were encountered: