Re: [Gnumed-devel] low Performance

[Ian Haywood]

On Sat, Jun 05, 2004 at 06:18:21PM +0200, Sebastian Hilbert wrote:
> On Saturday 05 June 2004 17:42, Hilmar Berger wrote:
> > Hi all,
> >
> > Maybe some points are really post-0.1 issues, on the other hand we
> > shouldn't implement algorithms that are known to be lowering perfomance.
> > Telling a new user that he could try the public db but should not wonder if
> > it is awfully slow could lead to rather unpleasant first encounters with
> > gnumed.
> Good point. I my opinion this should be dealt with before releasing 0.1 but 
A number of optimisations we know about: business object caching, preloading 
the waiting list, 
etc. most of which can be done post-0.1 IMHO

However, there is one thing I think we should consider now (because it only
gets harder from now on: 
for a lot of things, we have a search function which returns a list of id
numbers, then we instantiate business objects from each ID. This is were it gets
needlessly slow: we have a separate SQL query for each returned item. Instead 
the original search query should
be a "select * from", not "select pk from", and the search function then 
populates the business
objects with this data. 

Ideally, all DB communication should be done by a background thread, so the 
user can
start typing notes etc. while stuff is loading. I'm not sure about the best way 
to implement this yet.

Also, currently gnumed establishes a separate TCP connection for every commit 
transaction,
a obvious and simple point for optimisation.

Ian

pgp9f3QTnyZwd.pgp
Description: PGP signature