Bug 101467 - Template manager slow to load template previews
Summary: Template manager slow to load template previews
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.3.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Julien Nabet
QA Contact:
URL:
Whiteboard: target:6.0.0 target:5.4.2
Keywords: perf
: 105985 106576 (view as bug list)
Depends on:
Blocks: Template-Manager
  Show dependency treegraph
 
Reported: 2016-08-12 15:29 UTC by Yousuf Philips (jay)
Modified: 2017-08-17 13:49 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:


Attachments
CreateSalBitmap leak screenshot from Instruments.app (143.12 KB, image/png)
2017-08-08 14:12 UTC, Alex Thurgood
Details
Screenshot of memory leak from Instruments.app in TemplateLocalView (149.72 KB, image/png)
2017-08-08 14:14 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Yousuf Philips (jay) 2016-08-12 15:29:17 UTC
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
Comment 1 Yousuf Philips (jay) 2016-08-12 16:03:33 UTC
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
Comment 2 Xisco Faulí 2017-06-16 09:22:49 UTC
*** Bug 106576 has been marked as a duplicate of this bug. ***
Comment 3 Xisco Faulí 2017-06-16 09:23:00 UTC
*** Bug 105985 has been marked as a duplicate of this bug. ***
Comment 4 Alex Thurgood 2017-08-08 13:56:23 UTC
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.
Comment 5 Alex Thurgood 2017-08-08 14:10:50 UTC
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).
Comment 6 Alex Thurgood 2017-08-08 14:12:36 UTC
Created attachment 135290 [details]
CreateSalBitmap leak screenshot from Instruments.app

Enclosing screenshot of CreateSalBitmap leak using Instruments.app on OSX
Comment 7 Alex Thurgood 2017-08-08 14:14:45 UTC
Created attachment 135291 [details]
Screenshot of memory leak from Instruments.app in TemplateLocalView

Enclosing a screenshot of memory leaks in TemplateLocalView::insertItems
Comment 8 Telesto 2017-08-12 15:48:23 UTC
The MacOS leak is fixed; see bug 111567.
Comment 9 Julien Nabet 2017-08-12 19:02:40 UTC
(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!)
Comment 10 Julien Nabet 2017-08-12 19:45:20 UTC
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
Comment 11 Commit Notification 2017-08-13 10:16:08 UTC
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.
Comment 12 Commit Notification 2017-08-14 06:34:52 UTC
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.
Comment 13 Julien Nabet 2017-08-14 07:26:53 UTC
Could someone give a try with a daily build this patch http://cgit.freedesktop.org/libreoffice/core/commit/?id=68b0a61f7d4f89fd25b7725830b828c821da7dad ?
Comment 14 Alex Thurgood 2017-08-17 11:06:00 UTC
(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/
Comment 15 Alex Thurgood 2017-08-17 13:49:46 UTC
Seems fixed to me, I don't see any other large repeated leaks in those parts of the code previously mentioned, great job Julien :-)