kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
ossi at kde.org
Sun Aug 21 15:40:32 BST 2011
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
> > 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. ;)
More information about the kde-core-devel