[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] low Performance

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] low Performance
Date: Mon, 7 Jun 2004 00:23:11 +0200
User-agent: Mutt/

> 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

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]