I ran this more with normal builds and just the GC statistics. Here is what we see:<br>unmodified darcs:<br>469 MB total memory in use (3 MB lost due to fragmentation)<br>Total time 26.51s ( 29.76s elapsed)<br>Productivity 85.6% of total user, 76.2% of total elapsed<br>
<br>469 MB total memory in use (3 MB lost due to fragmentation)<br>Total time 26.59s ( 32.47s elapsed)<br>Productivity 85.6% of total user, 70.1% of total elapsed<br><br>469 MB total memory in use (3 MB lost due to fragmentation)<br>
Total time 26.54s ( 29.95s elapsed)<br>Productivity 85.5% of total user, 75.8% of total elapsed<br><br>With my patch applied:<br>554 MB total memory in use (4 MB lost due to fragmentation)<br>Total time 23.30s ( 31.56s elapsed)<br>
Productivity 83.1% of total user, 61.3% of total elapsed<br><br>554 MB total memory in use (4 MB lost due to fragmentation)<br>Total time 22.85s ( 26.33s elapsed)<br>Productivity 82.9% of total user, 71.9% of total elapsed<br>
<br>554 MB total memory in use (4 MB lost due to fragmentation)<br>Total time 22.88s ( 26.38s elapsed)<br>Productivity 82.8% of total user, 71.8% of total elapsed<br><br>Now that the profiler is disabled the productivity with my changes is less, the run-time is maybe improved by 2-3 seconds, and the memory usage has increased by almost 100 megs. I can only assume that the profiling is interfering with my results a fair bit.<br>
<br>Jason<br><br><div class="gmail_quote">On Wed, Sep 23, 2009 at 8:34 PM, Jason Dagit <span dir="ltr"><<a href="mailto:dagit@codersbase.com">dagit@codersbase.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br><div class="gmail_quote"><div class="im">On Wed, Sep 23, 2009 at 7:50 PM, Jason Dagit <span dir="ltr"><<a href="mailto:dagit@codersbase.com" target="_blank">dagit@codersbase.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
PS I'll try to reply to this with data to quantify the<br>
performance gains.<br></blockquote></div><div><br>Here we go.<br><br>I've compiled an unmodified profiling-enabled version of darcs in my path as darcs-prof-base.<br><br>darcs-prof-base says during a test run:<br>500 MB total memory in use (4 MB lost due to fragmentation)<br>
499 MB total memory in use (4 MB lost due to fragmentation)<br><br>Productivity 33.6% of total user, 29.5% of total elapsed<br>Productivity 30.4% of total user, 25.6% of total elapsed<br><br>After my patch darcs says this:<br>
516 MB total memory in use (4 MB lost due to fragmentation)<br>515 MB total memory in use (4 MB lost due to fragmentation)<br><br>Productivity 52.4% of total user, 36.3% of total elapsed<br>Productivity 52.4% of total user, 36.3% of total elapsed<br>
<br>The in-ram memory usage has increased about 15 megs. This is unfortunate, but from that we gain about 20% productivity.<br><br>Attached are pdfs showing how the heap usage has changed. Notice that the amount of heap consumed by lists goes way down and is replaced by an overall smaller usage of ByteString. I think the profiling data really speaks to this as being quite an improvement over the existing code, assuming we can work out the details of the encode/decode with respect to UTF-8.<br>
<br>Please let me know if you have questions!<br><br>Thanks,<br>Jason<br></div></div>
</blockquote></div><br>