Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Very slow backtraces in bytecode : debug infos read from the filesystem everytime #6302

Closed
vicuna opened this issue Jan 22, 2014 · 3 comments

Comments

@vicuna
Copy link

vicuna commented Jan 22, 2014

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.

@vicuna
Copy link
Author

vicuna commented Jan 24, 2014

Comment author: @gasche

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?

@vicuna
Copy link
Author

vicuna commented Mar 28, 2014

Comment author: @alainfrisch

The problem is addressed in the patch patch_backtraces.diff attached to #5899.

@vicuna
Copy link
Author

vicuna commented May 10, 2014

Comment author: @gasche

The fix was merged in trunk.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant