Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

using memory pool for the SearchTree Node

<< < (3/4) > >>

ollydbg:
@Jens:
I did a more serious test. Both patched version and unpatched build has no difference. Windows XP, Intel DualCore, 2G*2 memory. parsing the whole OpenCV library source.

Patched build test:

--- Code: ---Parsing stage done (1211 total parsed files, 60710 tokens in 0 minute(s), 25.172 seconds).

--- End code ---

Unpathched build test result:

--- Code: ---Parsing stage done (1211 total parsed files, 60710 tokens in 0 minute(s), 25.250 seconds).

--- End code ---


So, I just wondering why enable "memory pool" for searchNode has no effect. Maybe, it use too many STL like containers in searchNode class, like:


--- Code: ---class SearchTreeNode:public BlockAllocated<SearchTreeNode, 10000>
{
    ......
    protected:
        unsigned int m_depth;
        nSearchTreeNode m_parent;
        nSearchTreeLabel m_label;
        unsigned int m_labelstart, m_labellen;
        SearchTreeLinkMap m_Children;
        SearchTreeItemsMap m_Items;
};

And here is the definition:
/** SearchTreeLinkMap is the list of the edges towards other nodes. The character is the
key, and the node is the value */
typedef map<wxChar,nSearchTreeNode,less<wxChar> > SearchTreeLinkMap;

/** SearchTreeItemsMap contains all the items belonging to an edge */
typedef map<size_t,size_t,less<size_t> > SearchTreeItemsMap;


--- End code ---

Maybe, we should supply a optimized allocator for map ?!

ollydbg:

--- Quote from: thomas on July 04, 2009, 04:34:31 pm ---
--- Quote from: ollydbg on July 04, 2009, 03:21:24 pm ---I guess the reason of using this kind of mux is that they only want to  lock the operation in it's own compilation units :D Not operation between different units.
--- End quote ---
To be honest, I don't think this was intentional at all, it just incidentially happens to work without crashing  :)

--- End quote ---
These codes were horrible :shock:.

ollydbg:
I use a pool allocator supplied by libc++, but still can't gain much on performance, so, I suspect the neck bottle was not in SearchTree node allocation. :(

Some of my test code  is like below:


--- Code: ---
#include <ext/pool_allocator.h>
......

typedef map<wxChar,nSearchTreeNode,less<wxChar>,__gnu_cxx::__pool_alloc<std::pair<const wxChar,nSearchTreeNode> >  > SearchTreeLinkMap;

typedef map<size_t,size_t,less<size_t>, __gnu_cxx::__pool_alloc<std::pair<const size_t,size_t> > > SearchTreeItemsMap;


--- End code ---

oBFusCATed:
ollydbg: Do you know the first rule of optimizing code? It is: profile the code, so you know the exact place where the slowness comes from!

Though profiling C::B with gprof is impossible or quite hard for a normal human being (extraterrestrials are welcome to do so :) ).
You could manually profile it with wxStopWatch or some other form for doing it manually.

ollydbg:

--- Quote from: oBFusCATed on July 05, 2009, 05:06:53 pm ---ollydbg: Do you know the first rule of optimizing code? It is: profile the code, so you know the exact place where the slowness comes from!

Though profiling C::B with gprof is impossible or quite hard for a normal human being (extraterrestrials are welcome to do so :) ).
You could manually profile it with wxStopWatch or some other form for doing it manually.


--- End quote ---

Thanks for the hint.

I have read the source of CC, there are some code using wxStopWatch, they even supply a Macro to enable profiling, but It's quite hard to understand fully.. There's no document and even the comment in those code were poor.  :(

Today, I have update a little on the wiki page as a dev manual :D.

By the way ,several days ago, we are discussing parsing string from gdb command "whatis".

 it seems CC works badly in "template", so ,it's hard to support :D

Navigation

[0] Message Index

[#] Next page

[*] Previous page