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

[Thiago Macieira]

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.

> > > code size => shared memory, page faults on load.
> > 
> > That is true. But it is not proven. [...]
> 
> well, yeah, somebody has to do some real research. but the outcome is
> pretty predictable: qt's use of templates makes it extremely likely that
> significantly more code is executed, and the rather likely suboptimal
> code locality makes it probable that more unused code needs to be paged
> in from the much larger binary.

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.

I once wrote a benchmark comparing iterating over a QString to iterating over 
a gchar UTF-8 string using glib functions to get each UCS-4 character 
(ostensibly to prove that UTF-16 was better than UTF-8). The result was clear: 
Qt code was much faster, over 10x, compared to glib.

I wouldn't be surprised if we find the same about the other containers. Our 
benchmark isn't glib containers, but STL ones.

> well, of course. but given the availability of two equivalent solutions
> and people willing to maintain them, the one with a lower resource
> consuption will always be favorable.

Agreed. Which is why an existing service that we write should be in C++. We 
should not be required to learn glib in order to write a shared service.

If the GNOME developers decide they want to rewrite it, they are welcome to do 
so and dedicate resources.

Note I have never proposed rewriting existing shared service code in Qt.

> well, given that glib is an accepted dependency of qt (at least on the
> desktop), qt will always be an *additional* dependency. 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. Back on the Ubuntu 
Developer Summit in May last year, when I was presenting some of the 
technologies of Qt Mobility, there was a big interest in using them. Mark 
Shuttleworth asked if there were bindings for Python, which is the language 
that Canonical likes to use. 

But I'm sure other people wanted to use them from C too, they just didn't ask.

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.

> > reading settings is done via mmap()ed read-only memory. If the UTF-16
> > encoding isn't there, then the reader needs to create a QString from
> > the UTF-8 data.
> > 
> > Writing is done via D-Bus.
> 
> i know. exactly this has the potential for ping-pong if you do on-demand
> conversion of the actual store.

What ping-pong? If there's no UTF-16 encoding of the read-only and 
unchangeable data, you use QString::fromUtf8. If there is, you return 
QString::fromRawData.

When you write, you write with the encoding. Already-running applications must 
reopen the file, or scan to a later point in it anyway to see the new value.

> anyway, i really wonder whether insisting on utf-16 makes sense, assuming
> that the store is not abused for more than config data. KConfig and
> QSettings use utf-8, too, and nobody seriously complained about that
> afaik. the dconf client can implement caching of converted data just
> like the exising classes do.

I have. Please try this:

	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.

> > If you don't detach and you do replace the pointers, when do you
> > delete the old data?
> 
> the lifetime would be bound to the qstringdata, like the latin1 data in
> qt3-. i wouldn't bother with sharing the converted values - upon
> detaching, the format which is needed for the operation which caused the
> detach is made the primary (embedded) and only data of the clone.

So you're advocating the detaching method, not the convert-and-inline-replace 
one which QUrl tries to do and fails.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110821/246496bd/attachment.sig>