Hi, I think your work is very interesting. I am surprised that it makes almost no difference, because when measuring with callgrind, PoDoFo spends most of its time in malloc (and zlib which is because of the deflate algorithm).
Your boost based allocator is a very nice addition in my opinion. The code is
much simpler than your previous version and it gives people who want boost a
better performing version (even if negligible) and everyone else a working
version. So I am all for getting this into SVN. It does not hurt.
Regarding the pool memory which has to be free'd explicitly with
boost::singleton_pool<boost::fast_pool_allocator_tag,
sizeof(TRefCountedBuffer)>::release_memory(). Maybe it is time to add
podofo_library_init() and podofo_library_free() method (or something similar)
which can be used by applications to clear any allocated memory in pools from
PoDoFo. If PoDoFo gets some more memory pools (e.g. for PdfVariant) it will
get hard for the user to track which memory has to be free'd. Of course the
user is responsible for freeing every PdfObject/PdfDocument allocated by
his/her application by his/her self. Every thread using PoDoFo has to be
stopped, too.
I just played a bist with ParserTest and callgrind. For the PDFReference I get
3 647 953 calls to new from PdfVariant::operator=
1363133 calls to new from __gnu_cxx_new_allocator<PdfObject)::allocate
2285072 calls to new from std::string::_Rep_S_create
1453340 calls to new from
__gnu_cxx_new_allocator<std::_Rb_tree_node<std::pair<PdfName,PdfObject*>>::allocate
(i.e. PdfDictionary::AddKey)
893477 calls to new from PdfDictionary::operator=
new is the function called most after malloc and free, but I guess this is
because new uses malloc internally.
I see that this is a very special test and very different from creating a
PdfFile or working with streams. But I think we coulg gain more from a
PdfVariant and PdfObject allocator. Maybe also from a pool for
std::_Rb_tree_nodes.
best regards,
Dom
Am Monday 19 November 2007 schrieb Craig Ringer:
> Leonard Rosenthol wrote:
> > What's the performance difference?
>
> From what I can tell it's negligible in terms of overall performance. I
> haven't yet put together some long running tests, though, nor tests
> focusing on PdfRefCountedBuffer, so it's not good for much yet.
>
> It does strike me that we have a lot of other places where we allocate
> huge numbers of fixed size heap objects. Just for kicks, I introduced
> boost pool allocators into most of them ( all the complex PdfDataType
> subclasses, etc ) and found that there was a measurable but small
> performance hit and little effect on overall memory consumption. That
> was in the most fragmentation-oblivious testing, though - things like
> parsing a whole PDF or content stream, writing it out, and exiting.
>
> I'll need to chuck some better tests together before I can say much
> more. I figured I'd chuck that out there in the mean time, since I often
> find even small code snippets helpful when tracking back later. You know
> the feeling - "hmm, I think I looked at something vaguely like that...".
>
> --
> Craig Ringer
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Podofo-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/podofo-users
--
**********************************************************************
Dominik Seichter - [EMAIL PROTECTED]
KRename - http://www.krename.net - Powerful batch renamer for KDE
KBarcode - http://www.kbarcode.net - Barcode and label printing
PoDoFo - http://podofo.sf.net - PDF generation and parsing library
SchafKopf - http://schafkopf.berlios.de - Schafkopf, a card game, for KDE
Alan - http://alan.sf.net - A Turing Machine in Java
**********************************************************************
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ Podofo-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/podofo-users
