<html> <head> <style></style></head> <body class='hmmessage'><div dir='ltr'>Does slightly increasing or decreasing STR_STATIC_SIZE make a difference? Maybe the compiler is aligning on a larger boundary than the calculation assumes, or maybe a large static area increases cache misses by not allowing adjacent small strings to fit in the same cache block.<div><br></div><div>Are there ways to reduce the use of dynamic strings like what I did in .<a href="https://bugs.freedesktop.org/show_bug.cgi?id=89096" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=89096</a> ?</div><div><br></div><div>Regards,</div><div>William<br><br><div>To: poppler@lists.freedesktop.org<br>From: adam.reichold@t-online.de<br>Date: Mon, 29 Jun 2015 20:19:48 +0200<br>Subject: Re: [poppler] [RFC] Small string optimization in GooString<br><br><pre>Hello again,<br> <br>trying to get more insight into the referenced changes, I added some<br>microbenchmarks to test the performance of the GooString implementations<br>in isolation using Qt's built-in benchmarking facilities (with the<br>Linux-Perf-based measurement system).<br> <br>Attached are three graphs for construction of GooString instances with<br>variously sized C strings (which seems to be the most common operation<br>in the code base) showing CPU cycles, cache misses and branch misses<br>comparing the current (24/40), the compact (24/32) and adjusted (16/32)<br>variants normalized w.r.t. the the current version.<br> <br>The result seems to be that the compact variant is between 20 and 35<br>percent faster than the current version for short strings and marginally<br>faster for long ones. However, the number of cache and branch misses<br>looks much more irregular (note that the branch misses are scaled<br>logarithmically) even though the compact variant also seems to be better<br>than the current version more often than not.<br> <br>Insertion of C strings into GooString instances (the fourth graph) shows<br>a rather different behaviour with both the compact and adjusted model<br>being faster to insert long but sometimes slower to insert short<br>strings. The actual values are much closer together than for<br>construction, but I have to admit that I currently do not understand<br>this effect.<br> <br>Since insertion of short strings seems more common than insertion of<br>long strings in the code base, this might be a net loss. Even though I'd<br>assume that this should still be offset by the fact that construction of<br>short strings seems to be even more common.<br> <br>Best regards, Adam.<br></pre><br>_______________________________________________ poppler mailing list poppler@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/poppler</div></div> </div></body> </html>