[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kdevelop-devel
Subject:    Re: On Memory consumption of KDevelop-PG
From:       David Nolden <zwabel () googlemail ! com>
Date:       2010-01-09 0:43:07
Message-ID: 201001090143.07792.zwabel () googlemail ! com
[Download RAW message or body]

Am Samstag 09 Januar 2010 00:53:01 schrieb Alexander Dymo:
> > There is a few things we can do in future that would have a huge impact:
> > - Replace size_t with uint everywhere within the parser
> > - Move the "AST* parent" and "DUContext* ducontext" members out of the
> > AST, into a separate map in ParseSession, as they are not needed in most
> > cases. - Do the same thing with the "comments" member of CommentAST
> 
> I've tried to replace size_t with uint and remove AST*parent pointer. Here
>  are the results:
> 
> == my test file ==
> 						heap total	heap peak
> original:					506			399
> with uint instead of size_t	459			351
> without parent pointer		481			372
> 
> == kdevplatform ==
> 						heap total	heap peak
> original:					7826		193
> with uint instead of size_t	7640		193
> without parent pointer		7790		193
> 
> 
> Conclusions:
> for my large C/C++ file we save:
> size_t => uint: 			50M
> removing parent pointer:	20M
> 
> Total 70M which is not bad - only 330M will be used during the parsing for
> that file.
> 
> For kdevplatform the peak memory consumption isn't changed because AST's
>  are usually small and they are deleted when file is parsed. But these
>  changes can save us some malloc/realloc calls. If you look at heap total,
>  you'll see that we allocate 186M less after changing to uints and 36M less
>  after removing parent pointer.
> Total, we can allocate 222M less.
> 
> So, these optimizations wouldn't hurt at all. Shall I proceed and post
>  patches for review?

The 'uint' patches definitely. For the 'parent' thing, removing that doesn't 
save all that much even on your extrem test-case, so I think it shouldn't be 
removed. After all, the parent-pointers do provide a useful information for 
future use.

Greetings, David

-- 
KDevelop-devel mailing list
KDevelop-devel@kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
[prev in list] [next in list] [prev in thread] [next in thread]