Hi Mariano > ------------*2 100 000*So, in this case, I have to call two millions times > to OpenDBX. I think this is the reason why this takes 45 seconds.
Good point. This number of calls could hurt the performance of SqueakDBX a
little bit.
> 1) To have a function that returns ALL the fields of the row so that no to
> call odbx_field_value() for each field. If we have this the amount of calls
> in our example are reduced to 200 000
> This function can be somethign like this:
>
> const char*[] odbx_field_value( odbx_result_t* result )
Having such a function might be a good idea for interfacing OpenDBX from
interpreted languages but I would go a little bit further and would return
more information:
struct odbx_field_t {
char* value;
unsigned long length;
int flags; // NULL or not
}
const odbx_field_t[] odbx_field_list( odbx_result_t* result )
The big advantage is that you also get the field length (necessary for binary
values or as speedup for VARCHAR or CLOB fields) and it's a big enhancement
over odbx_field_value() where you can't distinguish between an error and a
NULL value.
> 2) The second thing is what I tried to told you in this email. Have a
> odbx_row_fetch
> for N rows. Something like what you do with "chunk" parameter in
> odbx_result(). Example:
> int odbx_rows_fetch( odbx_result_t* result, int numberOfRows )
> and then this function can call numberOfRows times to odbx_row_fetch().
>
> In addition, it's true that odbx_field_*() should be changed or create
> another pair of them to support this.
The number of calls would be reduced. Here's an example of the egde case when
all information would be prefetched:
1*odbx_fetch_row()
1*odbx_row_count(new)
n*odbx_field_list()
vs.
n*odbx_fetch_row()
n*odbx_field_list()
But it has some disadvantages:
- all records are stored in memory first (memory usage)
- odbx_field_list() would be more time consuming because it has to find the
required record each time as you can request a record at every position at
each call. Without this new functionality we could simply move to the next
record.
- We would need to change existing funtions (odbx_fetch_row) and would loose
backward compatibility
> I think step 1 is simpler than 2.
There might be valid cases for your second request but at the moment I don't
think that I would want to implement this. Let's concentrate on the first one
as this seems to be a bigger performance improvement for SqueakDBX and also
would be an enhancement for the other users of OpenDBX.
Norbert
--
OpenPGP public key
http://www.linuxnetworks.de/norbert.pubkey.asc
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------
_______________________________________________ libopendbx-devel mailing list libopendbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopendbx-devel http://www.linuxnetworks.de/doc/index.php/OpenDBX
