"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,
GDA_COMMAND_TYPE_SQL,
GDA_COMMAND_OPTION_STOP_ON_ERRORS);
GdaDataModel *model =
gda_connection_execute_select_command(
connection,
command, NULL, NULL);
gda_command_free(command);
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)) {
g_object_set_property(G_OBJECT(object),
gda_data_model_get_column_title(model, columns),
gvalue);
}
}
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) {
g_value_init(&pval,prop->value_type);
switch(prop->value_type){
case G_TYPE_STRING:
g_value_set_string(&pval, (gchar *)row[j]);
break;
/* more type cases */
}
}
g_object_set_property(G_OBJECT(object), field->name, &pval);
g_value_unset(&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?
Piotras
Attachment:
logs.tar.gz
Description: Binary data