Re: config listener API ...

On Thu, 2015-10-08 at 09:12 +0200, Stephan Bergmann wrote:
> On 10/07/2015 07:22 PM, Michael Meeks wrote:
> >     https://gerrit.libreoffice.org/19234
> >
> >     Which I want to use in Calc to hide the hideous costs there. Input
> > appreciated.
>
> What are those "hideous costs" exactly ?

        Oh =) good question. We have a configmgr setting that is changed
externally using the UNO API - enabling OpenCL (or not). We need to
check that inside our calculation loop to branch on it. We do an
innocuous:

        if (officecfg::Office::Common::Misc::UseOpenCL::get())

        Which reads beautifully =) in fact I love this type safe wrapper stuff
in the abstract (if not 100% of the implementation choices).

        Of the 15bn pcycles in the profile for re-calculating this sheet we
spend ~4bn pcycles essentially in this one method call (called 225k
times) =)

        That breaks down:

        3.3bn pcycles in Access::getByHierarchicalName
        0.5bn pcycles in 'comphelper::getComponentContext()'
                + the default parameter for 'get' ;-)
        0.2bn pcycles is allocating an OUString literal
                + (I assume for the 'path' that is made there)

        Which - I guess is fair enough; ~18k pcycles to get a config key seems
high but not totally excessive. The basic punch-line is that calling the
above is not a good idea to do 225k times in a row =)

        But then - the way that calc re-calculates is neither trivial, nor
extremely susceptible to - "split the loop invariant out" - there is
some deeply nested recursive goodness called from several places going
on =) So - hopefully this listener provides a better solution.

>   Do you have a pointer to a patch that makes use of the above commit
> to improve things?  That would probably explain things better.

        Sure - fair ask; so here - I'd just want a static global
ConfigurationListenerProperty which we can check with an in-lined
boolean comparison that goes no-where near configmgr on the hot path.

        I guess across much of the rest of the code we're used to coping with
the idea that its only the user that changes config keys so we have full
control over that in the dialog and/or putting up with out-of-date
cached config state =)

        Tor's idea of a shared global struct with state is interesting; but is
quite a big chunk of work I think. It could be split up by path (as now)
with a struct at the end of each node - but (I imagine) would involve a
lot of type introspection / wrangling as it's walked; and may make
startup rather slower too. I'm not sure that configmgr maintains a
flattened set of its layered data anyway (does it ?).

        Also - the "atomic change set" writing for configmgr settings (although
cumbersome at first glance) -should- map rather well to the way settings
dialogs work etc. so - in a global variable / structure world we'd want
to have that readonly I guess.

        Anyhow - I'm reasonably happy with the patch - unless there are better
ideas to improve it and/or integrate it with the existing wrappers -
I'll push it in a bit; and then add the calc hooks to make it useful.

        ATB,

                Michael.

-- 
 michael.meeks@collabora.com  <><, Pseudo Engineer, itinerant idiot