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
For large applications, symbol query time for Dr. Memory to locate malloc,
operator new and delete, and related routines is significant. On
subsequent runs our symbol cache greatly speeds this up, but the first run
can be quite slow (we're talking about as much as 30 seconds or more for
very large pdbs).
We may be able to perform a post-link step that stores addresses we care
about in the pdb. Or, perhaps just run our queries post-link and
pre-create symbol cache files (xref issue #192 where we may want to pre-generate symbol cache files to support pdbs that are too large to map into the address space with the app).
From bruen...@google.com on March 06, 2014 13:26:31
For large applications, symbol query time for Dr. Memory to locate malloc,
operator new and delete, and related routines is significant. On
subsequent runs our symbol cache greatly speeds this up, but the first run
can be quite slow (we're talking about as much as 30 seconds or more for
very large pdbs).
We may be able to perform a post-link step that stores addresses we care
about in the pdb. Or, perhaps just run our queries post-link and
pre-create symbol cache files (xref issue #192 where we may want to pre-generate symbol cache files to support pdbs that are too large to map into the address space with the app).
Original issue: http://code.google.com/p/drmemory/issues/detail?id=1467
The text was updated successfully, but these errors were encountered: