[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KConfig SQL backend
From:       Robert Knight <robertknight () gmail ! com>
Date:       2008-07-24 23:48:14
Message-ID: 1216943295.14181.10.camel () robert-laptop
[Download RAW message or body]

Hi Ivan,

What about 'cold' reads where the .ini files have not been read into the
file cache yet?  I would have thought that the main advantage of an SQL
database versus .ini files would be saving the cost of scattered reads
across many files when starting up an application.

I'd be interested in cold .ini files vs. cold database and 
hot .ini files versus hot database.

Regards,
Robert.

On Thu, 2008-07-24 at 17:48 -0400, Ivan Vasin wrote:
> I rewrote some of the mysql backend, cutting out the parts that
> convert everything to printable strings (since mysql can store in
> utf8) and converting it from using direct access via QSqlDatabase to
> using cached access via QSqlTableModel. These changes improved the
> backend's performance by at least a factor of two in all of the tests
> I ran. This new version is attached.
> 
> > 1) SQL with a good engine can be faster than flat files.
> 
> With the MyISAM engine using mysql-5.0.60 in Gentoo Linux on a 1.86GHz
> Pentium M, I recorded the following figures:
> 
> Data in 276 groups, nearly all 3 layers deep, ~21 entries each.
> 
> read:
> KConfigIniBackend 364 ms
> KConfigMysqlBackend 217 ms
> 
> write:
> KConfigIniBackend 4638 ms
> KConfigMysqlBackend 9904 ms
> 
> All figures are averages of 4 samples each.
> 
> As you can see, the mysql backend performs slightly better on reads,
> and is about twice as slow on writes, compared to the ini backend.
> This is with the "batched mode" parse/write that KConfig currently
> uses. It would be interesting to compare their performance with an
> "on-demand mode" parse/write.
> 
> > if you are interested in serious kconfig work i have a nice todo list
> > and some half-finished code for you. a word of warning: kconfig
> > developers have a tendency to disappear without a trace (two and
> > counting).
> 
> I am interested, but I won't have much time to commit to it before the
> end of August. Also unless I missed something in the API docs, here is
> another item for that todo list: making KSharedConfig support
> different backends.
> >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]