Re: [gnome-db] libgda performance issues

["Vivien Malerba" <vmalerba gmail com>]

On 6/20/07, Piotr Pokora <piotrek pokora gmail com> wrote:
>         Hi!
>
> Recently I compared similiar libraries. One is compiled against MySQL
> libraries, and another one is compiled against libgda 3.0.1.
> I used simple time command and also ran valgrind with callgrind tool.
> Libgda is even 10 times slower than pure MySQL usage :(
>
> Is this possible to disable thread support in libgda ?
> ( Use case here is forked Apache environment, so threads usage is useless. )

Threads are not used when running queries (that will probably be an
evolution, though), so the problem is not about threads.

The problem may come from the fact that the data retreived when
executing a SELECT command is first entirely copied in a GdaDataModel
(the one which is returned when executing the query), then read by the
application, and then destroyed. I recently implemented cursor based
data model access for the Postgres provider, maybe implementing it for
MySQL would help.

Would it be possible for you to send part or all of the testing code
you use (and of course the data as well) so I can examine where the
slowdown occurs?

> How can I make "light" SELECT queries, without involving the whole  gda library
> to check column types? I mean , I know what type is used for particular column
> ( through GObject&GValue  introspection ), so basically I could define how many
> columns I need to select and initialize specific GValues for them.
> Is this possible?

Column types determination is a very simple and quick process for
MySQL as the API reports that information (I think this could be
verified easily).

However, the current API could be expanded to allow to pass expected
GType for the columns, which would then eliminate completely the
process of column type determination (which is in fact a problem for
SQLite).

> I can send callgrind log if someone would like to analyze it with kcachegrind.

Yes, please.

Regards,

Vivien