Re: [Gnumed-devel] low Performance

[Karsten Hilbert]

> A number of optimisations we know about:
> business object caching,
we already do that in the clinical record

> preloading the waiting list,
once we *have* a waiting list

> 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:
Or at least we assume that's one of the main reasons. But I do
have the same feeling.

> 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. 
That's what I was thinking. I'll try that out fairly soon.

> Ideally, all DB communication should be done by a background thread,
Well, as I said, I lack the vision on how to do that.

> Also, currently gnumed establishes a separate TCP connection for every commit 
> transaction,
> a obvious and simple point for optimisation.
commits are rare but, yes

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346