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. ;)
