Re: [gnome-db] libgda performance issues

"Vivien Malerba" <vmalerba gmail com> wrote:

> > 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.

Kcachegrind clearly says that threads take much time of running process.
> 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.

I tested with MySQL , but target DB is completely unknown for me.
It may be MySQL , Posgres, SQLite or MSSQL, that's why libgda is taken into account
as DB abstraction layer. Generic solution ( provider unaware ) would be cool :)
> 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?

Code is *very simple*.

command = gda_command_new (query,
GdaDataModel *model =
                                command, NULL, NULL);

ret_rows = gda_data_model_get_n_rows(model);

for (rows = 0; rows < ret_rows; rows++) {
	gvalue = gda_data_model_get_value_at(model, columns, rows);
                        if(G_IS_VALUE(gvalue)) {
                                                        gda_data_model_get_column_title(model, columns),

This code ( used with MySQL API is **much** faster ):

for (j = 0; j < ret_fields; j++){
	field = mysql_fetch_field_direct(results, j);

        if ((prop = g_object_class_find_property(
                                                        (GObjectClass *)klass, field->name)) != NULL) {



                                        case G_TYPE_STRING:
                                                g_value_set_string(&pval, (gchar *)row[j]);

		/*  more type cases */
	g_object_set_property(G_OBJECT(object), field->name, &pval);

Half of the columns are string type and another half is int (more or less). 

> > 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).

Is it a problem if I initialize GValues ( with particular GType ) in the same order
as data returned by select?


Attachment: logs.tar.gz
Description: Binary data

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]