Review Request: Shared empty private class for KTimeZoneBackend

David Jarvie djarvie at kde.org
Mon Jun 13 09:58:05 BST 2011



> On June 13, 2011, 1:34 a.m., Michael Pyne wrote:
> > kdecore/date/ktimezone.cpp, line 622
> > <http://git.reviewboard.kde.org/r/101593/diff/1/?file=24338#file24338line622>
> >
> >     I received a crash based on this assert when testing with Kontact. I take it the refCount is 2 now. ;)
> >     
> >     After commenting out the assert everything starts and appears to work normally in my limited testing.

The refCount won't usually be 2 instead, because the 'impl' object isn't necessarily an empty KTimeZoneBackend (see for example the KSystemTimeZone constructor). I wouldn't want to remove the check carried out by the assert, which ensures that derived classes behave themselves, although it seems that it needs to be modified to also check for being the shared empty private class instance.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101593/#review3853
-----------------------------------------------------------


On June 12, 2011, 12:19 p.m., Volker Krause wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/101593/
> -----------------------------------------------------------
> 
> (Updated June 12, 2011, 12:19 p.m.)
> 
> 
> Review request for kdelibs, John Layt and David Jarvie.
> 
> 
> Summary
> -------
> 
> This patch makes KTimeZoneBackend use a shared empty private class, an optimization done in a few other places around KDateTime already.
> 
> This specific place turned up during memory-profiling KMail with folders containing ~100k messages. KMail (via KMime) creates one KDateTime object per message (using OffsetFromUTC mode), each of which contains two (empty) KTimeZone objects. The resulting 200k (identical) KTimeZoneBackend objects use about 20Mb of heap memory according to massif.
> 
> 
> Diffs
> -----
> 
>   kdecore/date/ktimezone.cpp f38deed 
> 
> Diff: http://git.reviewboard.kde.org/r/101593/diff
> 
> 
> Testing
> -------
> 
> kdecore unit tests still pass, KMail also still works fine, but I have no idea if this has side-effects on other, more complex use-cases
> 
> 
> Thanks,
> 
> Volker
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110613/3d358dd5/attachment.htm>


More information about the kde-core-devel mailing list