<html>
 <body>
  <div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
   <table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
    <tr>
     <td>
      This is an automatically generated e-mail. To reply, visit:
      <a href="https://git.reviewboard.kde.org/r/116577/">https://git.reviewboard.kde.org/r/116577/</a>
     </td>
    </tr>
   </table>
   <br />





<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
 <p style="margin-top: 0;">On March 3rd, 2014, 8:51 p.m. UTC, <b>Martin Gräßlin</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">recommendation: look at kwin/main.cpp kdemain()</pre>
 </blockquote>




 <p>On March 3rd, 2014, 10:42 p.m. UTC, <b>David Edmundson</b> wrote:</p>
 <blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
  <pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Thanks.

Copy and pasted for lazy:

#ifdef M_TRIM_THRESHOLD
    // Prevent fragmentation of the heap by malloc (glibc).
    //
    // The default threshold is 128*1024, which can result in a large memory usage
    // due to fragmentation especially if we use the raster graphicssystem. On the
    // otherside if the threshold is too low, free() starts to permanently ask the kernel
    // about shrinking the heap.
#ifdef HAVE_UNISTD_H
    const int pagesize = sysconf(_SC_PAGESIZE);
#else
    const int pagesize = 4*1024;
#endif // HAVE_UNISTD_H
    mallopt(M_TRIM_THRESHOLD, 5*pagesize);
#endif // M_TRIM_THRESHOLD


>From what I understand there are two schools of thought:
1) set the options to cleanup more aggressively
2) whenever we delete a load of stuff we say "hey, we're probably super fragmented now. Can you tidy up my memory please."

For a Plasma use-case, I think 2 maybe work better as we can know when we close an applet or dialog. 
</pre>
 </blockquote>








</blockquote>

<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I'm not sure which option is better. While (2) makes more sense since we do have that information, it means additional code and remembering to call it. Maybe we can just be more aggressive with memory and see if it has some noticeable side affects?</pre>
<br />










<p>- Vishesh</p>


<br />
<p>On March 3rd, 2014, 7:52 p.m. UTC, David Edmundson wrote:</p>








<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://git.reviewboard.kde.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
 <tr>
  <td>

<div>Review request for Plasma.</div>
<div>By David Edmundson.</div>


<p style="color: grey;"><i>Updated March 3, 2014, 7:52 p.m.</i></p>









<div style="margin-top: 1.5em;">
 <b style="color: #575012; font-size: 10pt;">Repository: </b>
plasma-framework
</div>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
 <table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">Call malloc_trim() when deleting a dialog

A dialog will typically contain lots and lots of tiny objects.

Tiny mallocs are not returned to the system immediately and are left for
us to re-use.

When we delete a dialog it would be a good time to release these.

This fixes the memory growth when repeatedly opening and closing the
widget explorer.

TBH: I don't /fully/ understand malloc_trim, but it does seem this patch makes a difference.

Also I think maybe this would be better being in the destructor of KDeclatarive::QMLObject as well?
or maybe we should tune the malloc options so it behaves better in general.

</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Testing </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
 <tr>
  <td>
   <pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">The following test (courtesy of Martin K) http://paste.kde.org/pjreffopt creates 10 dialogs, waits 5 seconds and deletes them.

Before: Memory usage in ksysguard goes up to 125Mb and stays there indefinitely.
After:Memory usage in ksysguard goes up to 125Mb and when the dialogs are removed goes back down to 35Mb
</pre>
  </td>
 </tr>
</table>


<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">

 <li>src/declarativeimports/core/dialog.cpp <span style="color: grey">(61e8d93)</span></li>

</ul>

<p><a href="https://git.reviewboard.kde.org/r/116577/diff/" style="margin-left: 3em;">View Diff</a></p>







  </td>
 </tr>
</table>








  </div>
 </body>
</html>