kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

[Oswald Buddenhagen]

On Sun, Aug 21, 2011 at 02:54:41PM +0200, Thiago Macieira wrote:
> On Sunday, 21 de August de 2011 12:25:52 Oswald Buddenhagen wrote:
> > yes, when the faulty module crashes. not so when it deadlocks or
> > busy-loops. also, a restart typically loses state.
> 
> True, but I don't remember that happening a single time to me in the past 3 
> years. I remember seeing people complain about kded taking 100% CPU, but it 
> hasn't happened to me.
> 
yes, things have stabilized meanwhile. but the problem will re-appear
during the kde5 cycle. it's inherent, after all.

> The extensive use of templates probably generates more code, but due to better 
> inlining, the code is potentially faster. So we're trading off code size for 
> code performance.
> 
probably. depending on the use case, this may or may not be a convincing
argument.

> > it's going to be interesting to push it down the stack enough that
> > people stop thinking about it.
> 
> Or make enough interesting services that are Qt-based.
>
well, that's the only way to do the pushing. it's not like we have any
political leverage to do it differently.

> The point is just as above: we, the KDE and Qt communities, are not
> required to learn glib in order to write a new service or library.
> 
some day maybe.
but to be able to join existing projects we have to learn glib anyway.
and if qt becomes a common framework for low-level things, others will
have to learn qt. we are going to fragment the ecosystem! :D

> What ping-pong? If there's no UTF-16 encoding of the read-only and 
> unchangeable data, you use QString::fromUtf8.
>
uhm, ok, i think i misunderstood you.

> If there is, you return QString::fromRawData.
> 
uhm, no, you must make a deep copy, otherwise you get a time bomb.
but yeah, no conversion, so pretty cheap.

> > anyway, i really wonder whether insisting on utf-16 makes sense, assuming
> > that the store is not abused for more than config data. [...]
> 
> 	valgrind --tool=massif kwrite
> 
> Then use the nice massifvisualizer to look at what consumes the most memory at 
> startup. It's KConfig, upwards of a couple of megabytes of heap.
> 
there is a 90+ kb file named katesyntaxhighlightingrc which seems to be
mostly a cache file. this use of kconfig borders on abuse. not sure if
there are other files on your system or kconfig really is that inefficient.
but generally speaking, a program which actually needs to query several
thousand keys on startup is definitely Doing It Wrong. and if it reads
only a few keys (of even a million), then the conversion cache will hold
almost nothing. on top of that, the cached converted values will be to
some degree shared with the objects which requested the values.

> So you're advocating the detaching method, not the
> convert-and-inline-replace one which QUrl tries to do and fails.
> 
uhm, maybe. it's not like the terminology would be self-evident. ;)