Re: [gnome-db] libgda-v4 performance problems
- From: "Vivien Malerba" <vmalerba gmail com>
- To: "Massimo Cora'" <maxcvs email it>
- Cc: gnome-db-list gnome org
- Subject: Re: [gnome-db] libgda-v4 performance problems
- Date: Wed, 9 Apr 2008 09:07:43 +0200
On Tue, Apr 8, 2008 at 9:17 PM, Massimo Cora' <maxcvs email it> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Vivien,
>
>
> Vivien Malerba wrote:
> > 2008/4/7 Johannes Schmid <jhs jsschmid de>:
> >
>
> > 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
>
>
> well, simple but good idea! Yes making it global may avoid to create and
> destroy everytime the GdaSet for every statement.
> I would probably prefer taking a GdaSet reference for every statement
> parsed, so there won't be the problem of lookup GdaHolders (if I
> understood correctly GdaSet uses a GSList internally): in case of many
> parameters, as in our example, it would need to iterate with a bad
> performance.
I thouht a list would be good enough, but if you want I can send you a
patch which replaces the list with a hash table, so you can tell me if
it makes a difference and if it's worth keeping the modif.
>
>
> > * you can use gda_holder_take_value() instead of
> > gda_holder_set_value() followed by gda_value_free().
>
> I'll have a look at this too
>
>
> > * putting all the queries within one single transaction is usually
> > _much_ faster with SQLite (maybe more than 10 times faster)
> >
>
> do you mean that we should avoid the transactions? I thought it was
> faster, at least with others db it is...
No, I meant: use a BEGIN before the first INSERT and do a COMMIT after
the last INSERT, it should improve performances.
Cheers!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]