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

[Karsten Hilbert]

> Just use thread safe message queues both directions instead of directly 
> invoking procedures.
I am reading up on it currently.

> However, it should not be neccessary at all:
You never never go, you never never know ...

                              Minh, Hue', Vietnam

> 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. 
I know ! But I like it that way for obvious reasons ;-))   It
makes one painfully aware of crappy code.

> Using this, you 
> will find that tyour reponse times for your queries will drop to maybe 10%
I sure hope so. The amount of "server lowness" would be a
tunable anyways, such that one could say "load the first 100
matches only" instead of the first 10 on a slow server.
Expecting more matches while also expecting marginal
response times is not sane.

> 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
Of course I don't !  I can't even, since I don't have any EMR
data in the database ...   I load matching IDs first, then
load "lastnames, firstnames, dob" for those. It's that second
step that takes 60 seconds for 207 patients (BTW, that drops
to around 50 when no concurrent import is going on).

> 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.
I tried doing processing in the idle loop when implementing
the phrase wheel. Let me tell you that interactivity performance
sucked big time. If you read the docs it says that the
wxWindows idle loop isn't particularly well suited for much
processing for some reason or other. Haven't tried again,
lately, though.

> -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)
The check itself should be done inside the business object.
The widget._on_receive_focus() just does my_data =
curr_pat['the data I need'] and class curr_pat should be
clever enough to retrieve non-cached items. Reason being for
not having that implemented yet is that listening to backend
notifies only works for the first Listen() - seems we are
missing some auditing here and I fail to see an Unlisten()
implementation yet...

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

> I suggest to use "lazy import" for al notebook widgets for a start.
At what level ? Plugin-level stubs or plugin-specific deferral
of time-intensive operations until <plugin>.ReceiveFocus() ?
The latter I already implemented in some plugins (show_docs,
xdt_viewer, manual_viewer). We should split out the
html-viewer used by several plugins such that it only gets
loaded once (manual, guidelines, STIKO, ...).

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