[Development] optimizing QComposeInputContext / TableGenerator?

[Milian Wolff]

On Monday 19 January 2015 20:48:54 Olivier Goffart wrote:
> On Monday 19 January 2015 20:15:22 Milian Wolff wrote:
> > Hello all,
> > 
> > when I run my heaptrack [1] tool on Qt 5 applications, I often stumble
> > upon
> > the compose TableGenerator. It initializes many QStrings and also consumes
> > ruoghly 400KB of memory. I wonder whether we could optimize this somehow?
> > 
> > The best approach of course would be to have a OpenDesktop standard that
> > allows mmapping the compose table in and using it from there. Probably not
> > feasible. Creating our own cache brings the usual issues of having to
> > update the cache when the original changes... So what I wonder about is
> > whether one could delay the table generation? I usually don't use the
> > compose key, so my naive assumption would be that lazy-loading this table
> > would help the common case of startup quite a bit already. Or is this
> > required for other things that I don't expect?
> 
> Looking at the hotspot from void TableGenerator::parseKeySequence:
> 
>  elem.value = QString::fromLocal8Bit(composeValue).at(0).unicode();
> 
> So if I understand correctly, it needs to convert the full line to QString
> just to take the first character.  Surely this can be improved.

It can, indeed. But funnily enough it's not going to be much faster, at least 
in the tests I did. Still, one should probably be doing this anyways. I'll try 
to dig up my patch for that and sent it to Gerrit. It's a pity that one cannot 
just convert a const char* to a QChar directly, i.e. without any allocations. 
One cannot even reuse the same QString buffer to my knowledge...

> The code is here:
> http://code.woboq.org/qt5/qtbase/src/plugins/platforminputcontexts/compose/g
> enerator/qtablegenerator.cpp.html#_ZN14TableGenerator16parseKeySequenceEPc
> 
> But yes, some mmapable on-disk cache would probably be the best.
> One would just need to make sure that the cache is invalidated properly when
> it should.

Which is a can of worms, but yes - probably worth it in the long run. I wonder 
whether this is handled by libxkbcommon.

Bye

-- 
Milian Wolff | milian.wolff at kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions