Re: [gnome-db] libgda-v4 performance problems
- From: "Vivien Malerba" <vmalerba gmail com>
- To: "Johannes Schmid" <jhs jsschmid de>
- Cc: gnome-db-list gnome org
- Subject: Re: [gnome-db] libgda-v4 performance problems
- Date: Tue, 8 Apr 2008 11:02:13 +0200
2008/4/7 Johannes Schmid <jhs jsschmid de>:
> Hi!
>
> After I already reported some performance problems with libgda-3.0 we
> updated our whole database stuff to libgda-v4. It's a bit faster but we
> still have bad performance for any query.
>
> callgrind output says about:
> 30% libgobject (g_object_set)
> 21% libglib (g_list_append)
> 21% libc (mcount/malloc)
> 14% libsqlite
I'll run the test and try to see where things could be improved.
>
> This is already much better than libgda-3.0 where libsqlite did not
> appear at all but still a lot of time is wasted. We have a quite
> synthetic test case in the anjuta module in GNOME-SVN:
>
> In plugins/symbol-db/test there is a test called "benchmark" and you
> have to call it with a directory of sources (full path). To get
> comparable results you might want to do something like
>
> # ./benchmark /home/jhs/devel/anjuta-trunk/libanjuta/
>
> It parses all those files with ctags and puts the result in a sqlite
> database.
>
> Would be nice if someone could make suggestions to improve the
> situation!
I've just had a quich look at the code, and here is what I can think of:
* avoid creating a GdaSet for the parameters everytime
sdb_engine_add_new_file() is called (reuse the same one once created),
you can also keep references to the individual GdaHolder objects
within the GdaSet if you want. You can also create a unique GdaSet
object which contains all the parameters for all the statements you
have in the plugin, and use it everytime (only set the values which
need to be set), have a look at the bottom of create_table_object() in
gda-meta-store.c
* you can use gda_holder_take_value() instead of
gda_holder_set_value() followed by gda_value_free().
* putting all the queries within one single transaction is usually
_much_ faster with SQLite (maybe more than 10 times faster)
Cheers,
Vivien
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]