Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations bkrike on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Line taking too long to execute, and is not consistent 1

Status
Not open for further replies.

possiblyasleep

Programmer
Aug 4, 2005
2
US
I have been analyzing project load times of a program we are currently developing, and have been trying to figure out why it is going slower than we think it should. I have narrowed the problem down to a single line of code, but unfortunately can not account for why it is behaving as it is. The line is as follows:

Code:
 cAddRefPtr< cProperty<T> > newProperty = new cProperty<T>(pRefPropertyName);

This line generally takes 0.01 - 0.02 seconds to execute, but occaisionally, it can take upwards of 0.6 seconds to finish. (I'm using the hardware performance counter to get timings). This wouldn't seem that bad, except that that line executes 10,000+ times while loading a project.

The pointer is a COM IP Pointer, and is automatically addreffed, which takes less than 0.001 seconds. The data structure being created is not complex, and its constructor and base class constructors should not take more than a few thousandths of a second to execute (though this is an assumption, I'm having trouble actually test it). The amount of memory allocated by the new is around 320 bytes. The constructor's argument (pRefPropertyName) is a std::wstring that is passed into the function containing this line.

My main problem is that I can't understand why it would vary so much. I have ensured that no other threads are interfering. My only hypotheses are that it is occaisionally running out of heap and needing to allocate more, or that there is some slowdown due to the template. However, even if I statically allocate enough memory at startup, it still runs into those slowdowns. I am not sure how to test to see if the template is causing the problem.

If any one has run into similar issues, or has any hint for what to look at, or where to make an optimization, please let me know. If you need more information please ask.

Thank you.
 
Well I'd belive it is in the area you suggest - with the need to allocate heap (you stated you call it some 10.000+ times) especially if its a different pRefPropertyName instance for every call.

I ran into a similar problem, where I had a std::map<std::string, std::string> collection with some 20.000 entries that was a bit slow to build/destruct. Since the string where actually not to be changed I could modify it so instead of std::string I defined a class where all string data was just pointing into a big, previously allocated, vector. And it solved it for me.
(ie I read all string data from file into a single vector and built the map holding classes that just point into that vector)

Point is - using std::(w)string is a bit costly since it does some allocation of its own and I can imagine that creating/destroying 10.000+ std::wstrings could have such an effect.

You say the data type isn't complex - but does is hold a std::wstring? Then it is kind'a complex :)

Some suggestions to try out
1)
Pass pRefPropertyName as a const std::wstring&, combined with the caller using the same std::wstring instance for each call. There could be come reallocating done but I'd guess it should be far less at least.

2) Let the data type be really simple (if not already). Ie no wstring but w_char* or w_char [fixedLength] instead.


/Per

www.perfnurt.se
 
Thanks for the tip, I changed how the string was handled, and this improved the common case quite a bit.

I actually was looking at it after that and realized that a base class I had overlooked previously was needlessly accessing the disk every time it was constructed. I guess that is what I get for assuming they were not taking much time. After fixing that and the string issue, the line is executing in an expected time frame.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top