[Top][All Lists]

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

Re: [Gnumed-devel] emr browser speedup

From: Ian Haywood
Subject: Re: [Gnumed-devel] emr browser speedup
Date: Sun, 28 May 2006 16:33:39 +1000
User-agent: Debian Thunderbird 1.0.7 (X11/20051017)

Karsten Hilbert wrote:
> Hi Syan,
> I am reviewing your work on this. Thanks for your input.

> Anyways, what I'm trying to say, the EMR browser data
> retrieval code should perhaps rather operate on simple dicts
> which the middleware delivers from the database. 
I agree completely. The middleware needs a serious diet ;-)
It's job should be fetching and maintaining caches of dicts in a generic
way, the actual form of the dicts should be determined by backend views,

IMHO we could have a central registry of queries and a single cache, which is
a big dictionary where the keys are a tuple (query_name, arg1, arg2, ...)

I'd be wary of multiple threads, as these imply multiple DB connections.
Remember each connection means the backend has to fire up a postgres process
on the server, as well as TCP overhead, then these backends start competing for 
By the time you've finished, it may not be faster. (of course,
I'm happy for this to be benchmarked and so proved wrong ;-)

Better IMHO a "query queue" feeding a *single* background worker thread, queries
which are "urgent" (ie. the user is waiting on the result) go to the
head of the queue, prefetches go to the back.
When the results are in, the worker thread then passed data to the GUI thread
via wxCallAfter ()

> Part of
> which (sub-encounter/sub-episode data) should probably be
> piped through Cheetah to get some nicely formatted HTML
> (template user selectable) to be displayed on the right hand
> pane. 
Yep, sounds good.


reply via email to

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