Opening the templates in the start center with the templates collection available through --enable-extra-template with a cleared profile causes it to take ~3.5 minutes to load on my laptop is a i5 3rd generation with 4gb ram on Windows 8.1. The same test on the same machine with Ubuntu Mate 16.04 takes 30 seconds. Version: 5.3.0.0.alpha0+ Build ID: 18009fe8fbe3982141ddca3f1fcd0900a63150a6 CPU Threads: 4; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@42, Branch:master, Time: 2016-08-12_06:41:25 Locale: en-US (en_US); Calc: CL
Linux build is from august 10th. Version: 5.3.0.0.alpha0+ Build ID: 8dba3b6b8ab55c5c32cab8ebad795039591bc4e6 CPU Threads: 4; OS Version: Linux 4.4; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group Alex mentioned in bug 61471 that it took ~1.5m on his Intel Core 2 Duo mac mini (2010) and Intel Core i7 macbook pro (2013). Version: 5.3.0.0.alpha0+ Build ID: 3a668616968dbce778c54ec56847828efa7bdb6d CPU Threads: 2; OS Version: Mac OS X 10.11.6; UI Render: default; Locale: fr-FR (fr.UTF-8); Calc: group
*** Bug 106576 has been marked as a duplicate of this bug. ***
*** Bug 105985 has been marked as a duplicate of this bug. ***
Well profiling with Instruments.app under Mac OSX and my master build shows that LO leaks memory fairly importantly in this function block of code in templatelocalview.cxx : void TemplateLocalView::insertItems(const std::vector<TemplateItemProperties> &rTemplates, bool isRegionSelected, bool bShowCategoryInTooltip) { mItemList.clear(); std::vector<ThumbnailViewItem*> aItems(rTemplates.size()); for (size_t i = 0, n = rTemplates.size(); i < n; ++i ) { const TemplateItemProperties *pCur = &rTemplates[i]; TemplateViewItem *pChild; if(isRegionSelected) pChild = new TemplateViewItem(*this, pCur->nId); else pChild = new TemplateViewItem(*this, i+1); pChild->mnDocId = pCur->nDocId; pChild->mnRegionId = pCur->nRegionId; pChild->maTitle = pCur->aName; pChild->setPath(pCur->aPath); if(!bShowCategoryInTooltip) pChild->setHelpText(pCur->aName); else { Each invocation of else pChild = new TemplateViewItem(*this, i+1); causes 400 bytes of memory to leak. Multiply that by the number of templates you have and memory consumption quickly skyrockets.
In addition : SalBitmap* AquaSalInstance::CreateSalBitmap() { return new QuartzSalBitmap(); } lines 958-961 of salinst.cxx also appear to leak memory at each invocation (assuming one per template).
Created attachment 135290 [details] CreateSalBitmap leak screenshot from Instruments.app Enclosing screenshot of CreateSalBitmap leak using Instruments.app on OSX
Created attachment 135291 [details] Screenshot of memory leak from Instruments.app in TemplateLocalView Enclosing a screenshot of memory leaks in TemplateLocalView::insertItems
The MacOS leak is fixed; see bug 111567.
(In reply to Telesto from comment #8) > The MacOS leak is fixed; see bug 111567. This one is not specific MacOs. The specific MacOs (perhaps ios too I don't know) is AquaSalInstance::CreateSalBitmap (Alex: great you give a try to bugtrackers related to leaks! the XCode tool seems indeed quite good!)
I submitted a patch about SalBitmap https://bugs.documentfoundation.org/show_bug.cgi?id=101467 About BitmapEx, I must recognize I don't know how it destroys SalBitmap
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=68b0a61f7d4f89fd25b7725830b828c821da7dad Related tdf#101467: fix a leak with pSalMask (vcl/bitmapex) It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Julien Nabet committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=efbbf7fd668e189e41c80232e11185bfd25ee2a0&h=libreoffice-5-4 Related tdf#101467: fix a leak with pSalMask (vcl/bitmapex) It will be available in 5.4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Could someone give a try with a daily build this patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=68b0a61f7d4f89fd25b7725830b828c821da7dad ?
(In reply to Julien Nabet from comment #13) > Could someone give a try with a daily build this patch > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=68b0a61f7d4f89fd25b7725830b828c821da7dad ? I'm rebuilding master now, will check back when it is finished/
Seems fixed to me, I don't see any other large repeated leaks in those parts of the code previously mentioned, great job Julien :-)
The fix does not solve bug 105985 which was Dupe of this bug.