Re: [Gnumed-devel] emr browser speedup

[Ian Haywood]

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 
disk.
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.


Ian