Bug 428948 - Performance issue: loading a big C++ object can take several minutes (20 min)
Summary: Performance issue: loading a big C++ object can take several minutes (20 min)
Status: RESOLVED FIXED
Alias: None
Product: TCF
Classification: Tools
Component: Agent (show other bugs)
Version: 1.2   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: 1.3   Edit
Assignee: Eugene Tarassov CLA
QA Contact: Eugene Tarassov CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-24 13:37 EST by Benoit Perrin CLA
Modified: 2014-05-27 23:08 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Benoit Perrin CLA 2014-02-24 13:37:37 EST
We have very big C++ vxworks kernel module (300Mb) from a customer. This kernel module is not fully linked and so it contains lots of sections and lots of relocation entries (more than 4 millions). VxWorks can load this module dynamically.

But in that case, the symbol file / debug info parser of the TCF agent takes several minutes (20 minutes) to load the symbol file and to process all the debug info.

I think the issue relies on the tons of address ranges the code and to relocate and the huge amount of relocations to handle: for *each* address to relocate, the agent has to look within the 4 million of relocations to found the correct one.

Moreover, during the load of the file, the agent does not answer any request, as the load occurs on the dispatch thread.

As the test case is a customer application, we can share it.
Comment 1 Benoit Perrin CLA 2014-03-17 13:09:24 EDT
The issue has been fixed by the commit:

commit b6dbf57ef1a81be9bef809286a9378711cb28fdd
Author: Eugene Tarassov <eugene.tarassov@xilinx.com>
Date:   Fri Mar 14 20:24:27 2014 -0700

    TCF Agent: improved speed of DWARF relocations


Now the load of the module takes less than 10s, and debug info retrieval (symbols or line info) takes less than 5s.
Comment 2 Martin Oberhuber CLA 2014-03-18 16:40:47 EDT
Guys, this is AWSOME !!!

Big Thanks to Eugene for fixing this -- and to Benoit for finding the issue.