gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] Re: patient search widget timings -more comment


From: Horst Herb
Subject: Re: [Gnumed-devel] Re: patient search widget timings -more comment
Date: Fri, 28 Mar 2003 10:21:32 +1100
User-agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312

Karsten Hilbert wrote:

I guess I *must* learn how to do thread-safe update of data
structures ... Would help a lot for the patient selection
thing.  Anyone got good pointers for that (not just general
thread-bla-bla) ?

Just use thread safe message queues both directions instead of directly invoking procedures.

However, it should not be neccessary at all:
1.) your "benchmarking" server has specifications way too low to be reasonable. While a P133 is certainly good enough, 40 MB of RAM are not. 128 MB are usually the bare minimum to run any sizeable relational database. We might write one day a different ackend for lower-end hardware (like using Metakit instead), but for now we focus on Postgres and on a server that has a minimum of 128 MB of RAM. bUsing this, you will find that tyour reponse times for your queries will drop to maybe 10%

2.) *Don't* try to load a whole patient record at once when a patient has been selected. Load what is displayed only, and the rest in the idle loop
Algorithm:
-1- load what is visible
-2- start "idle loop loading" one item at a time (not threaded!). Check whether item is loaded before loading in idle loop. -3- "on focus/on visible" events check whether the item to display is already loaded, and if not, it does so (should only take a small fraction of a second for any one display)

That way, you can always get responsiveness of the user interface (less than a second from selecting a patient)

I suggest to use "lazy import" for al notebook widgets for a start.

Horst





reply via email to

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