[odb-users] using ODB for interactive access

Panayiotis Georgiou ps.georgiou at gmail.com
Tue Nov 7 12:10:47 EST 2017


Hi Boris,

Thanks for the reply. I have profiled my code to get some sense what is the
increase in time when operating directly on the database compared to
holding the data in memory in a data-structure for a simple table. From the
test, it seems that the database access is not the bottleneck causing the
issue although there is some expected increase in times.

For comparison here are the results:

The functions affected by the implementation of our QAbstractItemModel were
the rowCount() [counts the records in a query] and data() [reads the data
at a particular column of a record].

* For 1000 records accessed directly from the database:
  rowCount() - 190ms
  data() - 160ms

* For 1000 records accessed from a dynamic data-structure in-memory:
  rowCount() - 0.003ms
  data() - 5ms

As you can see, there is an increase but it should be negligible for a
single access (order of 0.2ms per request ).

I think it's in fact Qt that makes unnecessarily large amounts of requests.

Running the code in Release rather than debug and outside VisualStudio has
also helped significantly.

Thanks,
Panayiotis.


On Tue, Nov 7, 2017 at 1:42 PM, Boris Kolpackov <boris at codesynthesis.com>
wrote:

> Panayiotis Georgiou <ps.georgiou at gmail.com> writes:
>
> > Although this approach keeps the data presented by the view always in
> sync
> > with the database, this approach seems very slow for interactive use. For
> > example. clicking on a cell on the table-view to edit it might take maybe
> > 1-2 seconds to respond.
> >
> > [...] (our database is relatively small)
>
> I am very surprised by this. With SQLite a read operation on a small
> database definitely shouldn't take seconds. I think there is something
> else going on. The only plausible explanation that I can think of would
> be locking in heavy concurrent access but I doubt you have that.
>
> Try to isolate the equivalent database access logic into a separate
> test and see how it measures.
>
> Boris
>


More information about the odb-users mailing list