<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="http://git.reviewboard.kde.org/r/108962/">http://git.reviewboard.kde.org/r/108962/</a>
</td>
</tr>
</table>
<br />
<blockquote style="margin-left: 1em; border-left: 2px solid #d0d0d0; padding-left: 10px;">
<p style="margin-top: 0;">On February 14th, 2013, 8:10 p.m. UTC, <b>Vishesh Handa</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;">Seems good! I was a little scared to do this again.
I was also thinking about using the OptimizedByteArray or something similar. We're storing a LOT of urls which have common parts.</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;">Yeah, maybe. I don't know. On my system with this patch it peaks at about 200 entries, which is a fair few, and they are probably mostly duplicates, it's true. But it only happens when the system is heavily indexing, and so the memory used is totally dwarfed by virtuoso-t's 500MB memory usage.</pre>
<br />
<p>- Simeon</p>
<br />
<p>On February 14th, 2013, 5:10 p.m. UTC, Simeon Bird wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('http://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 Nepomuk and Vishesh Handa.</div>
<div>By Simeon Bird.</div>
<p style="color: grey;"><i>Updated Feb. 14, 2013, 5:10 p.m.</i></p>
<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;"> BasicIndexingQueue: Use stacks instead of queues
Similar to 2f33141aa6716550e38b11ec9a0b000dd74eea79, reverted by
b651f9231ac30072418bb06d602951f0f05da22c.
The reason this broke recursive indexing was that it was taking the top
item from the stack with m_iterators.first(), but
QStack::top() == QVector::last(). Since we no longer have m_iterators,
anyway, we can just use a stack.
Commit message from 2f33141aa:
Iterating depth first will consume less memory than going breadth first.
Also stacks are based on QVectors which avoid the unnecessary extra
allocation in QLists.
Apply on top of Vishesh's fix for bug 310777
</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;">Recursive indexing still works! m_paths is smaller than it used to be.</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>services/fileindexer/basicindexingqueue.h <span style="color: grey">(5d1c190)</span></li>
<li>services/fileindexer/basicindexingqueue.cpp <span style="color: grey">(b581786)</span></li>
</ul>
<p><a href="http://git.reviewboard.kde.org/r/108962/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>