On 6/20/07, Piotr Pokora <[EMAIL PROTECTED]> 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 _______________________________________________ gnome-db-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-db-list
