Review Request: Shared empty private class for KTimeZoneBackend

[Michael Pyne]

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



kdecore/date/ktimezone.cpp
<http://git.reviewboard.kde.org/r/101593/#comment3132>

    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.


- Michael


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/30ee3c0a/attachment.htm>