[poppler] [RFC] Small string optimization in GooString

[Albert Astals Cid]

El Dijous, 2 de juliol de 2015, a les 00:24:29, Adam Reichold va escriure:
> Hello,
> 
> Am 01.07.2015 um 23:19 schrieb Albert Astals Cid:
> > I welcome the interest in making stuff faster but is GooString really the
> > bottleneck in any of the use cases of poppler?
> 
> My aim is definitely not making things faster here, it is reducing
> memory usage without sacrificing performance. So staying exactly where
> we are but getting small strings down to 32 bytes is basically what I
> aim for. (All the benchmarks and graphs are anticipatory obedience as to
> show that it does not decrease performance.)
> 
> > Sure we can probably make it 1% faster and that's great but usually the
> > "slow" stuff is somewhere else, no?
> 
> Of course, my profiler tells me that when using the Qt frontend and the
> Splash output device with real PDF files and at realistic resolutions,
> almost all of the time is spent in deflate and alpha blending. I do have
> an idea how to reduce the time Poppler::Page::renderToImage spents
> within Splash::compositeBackground but that seems to be a hornet's nest
> w.r.t. toolkit politics. :-\ (I did start to try to improve that method
> using intrinsincs but have yet to beat GCC's performance with the
> result... :-()
> 
> > Or have you found some use case that is heavely dependant on GooString
> > speed?
> We certainly throw a lot of small strings around and the changes are
> reasonably localized (compared for example with just replacing GooString
> with std::string everywhere which seems like the right thing to do), so
> I guess having some fun doing it and it seeming to work fine would be
> reason enough for me.
> 
> > Please do not take this as a "stop doing this", i'm sure you're doing it
> > and you're either learning a lot or having fun, so continue doing it and
> > see where we end up :)
> 
> Of course, it might not be reason enough to include the patch. Do you
> consider taking just the memory layout fix so that the misleading
> comment about the final object size is resolved?

The simpler the better, and from there we can build up :)

Cheers,
  Albert

> 
> Best regards, Adam.