gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Measurements - lessons from other EMRs - limiting the


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] Measurements - lessons from other EMRs - limiting the amount of lab data fetched
Date: Wed, 17 Jul 2013 23:02:42 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Jul 17, 2013 at 07:36:44PM +0000, Jim Busser wrote:

> 1) it currently takes me more than 20-25 seconds from the
> time I insert a unique patient name in the search box, and
> having displayed for me the unique patient

That certainly affords optimization. I took a look a few
times but didn't dig deep enough to identify the real
culprit. It doesn't take that long for me, however (even
across my LAN) but then I probably don't have as much data
per patient.

> 2) while, admittedly, performance should be faster if I
> was not running in 'debug' mode, and maybe if I were running
> GNUmed under a native graphics display rather than through
> X11, I am -- OTOH -- running the database locally on my 1
> year old MacBook Pro, and surely some of the speed gains
> that would be achieved by running NOT in debug mode, in a
> native GUI, would be offset if I should have to fetch the
> data off a server?

I doubt the gains would be anywhere close to what a "slow"
link would cost you.

> so I want us to be ready and to have already thought of
> some of what we need to take into account.

Typically optimization works a lot different than what we
intuitively think. It goes like this:

- identify the slow places of the workflow (opening a patient)
- narrow down which part(s) are slow at the workflow level
  (certain plugins ? plugin order ? functions ?)
- profile the slow parts to find out which parts of the
  code take the most time
- look whether a whole new concept, or an algorithmically
  different approach, or some micro-optimization (shave
  off a few cycles here and there) is in order

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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