[poppler] [RFC] Small string optimization in GooString

[William Bader]

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.
Are there ways to reduce the use of dynamic strings like what I did in .https://bugs.freedesktop.org/show_bug.cgi?id=89096 ?
Regards,William

To: poppler at lists.freedesktop.org
From: adam.reichold at t-online.de
Date: Mon, 29 Jun 2015 20:19:48 +0200
Subject: Re: [poppler] [RFC] Small string optimization in GooString

Hello again,
 
trying to get more insight into the referenced changes, I added some
microbenchmarks to test the performance of the GooString implementations
in isolation using Qt's built-in benchmarking facilities (with the
Linux-Perf-based measurement system).
 
Attached are three graphs for construction of GooString instances with
variously sized C strings (which seems to be the most common operation
in the code base) showing CPU cycles, cache misses and branch misses
comparing the current (24/40), the compact (24/32) and adjusted (16/32)
variants normalized w.r.t. the the current version.
 
The result seems to be that the compact variant is between 20 and 35
percent faster than the current version for short strings and marginally
faster for long ones. However, the number of cache and branch misses
looks much more irregular (note that the branch misses are scaled
logarithmically) even though the compact variant also seems to be better
than the current version more often than not.
 
Insertion of C strings into GooString instances (the fourth graph) shows
a rather different behaviour with both the compact and adjusted model
being faster to insert long but sometimes slower to insert short
strings. The actual values are much closer together than for
construction, but I have to admit that I currently do not understand
this effect.
 
Since insertion of short strings seems more common than insertion of
long strings in the code base, this might be a net loss. Even though I'd
assume that this should still be offset by the fact that construction of
short strings seems to be even more common.
 
Best regards, Adam.

_______________________________________________
poppler mailing list
poppler at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/poppler 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/poppler/attachments/20150629/bb990fe9/attachment.html>