Re: [Gnumed-devel] some 1st cut proposed optimizations to emrbrowser

[Sebastian Hilbert]

On Saturday 27 May 2006 13:44, Syan Tan wrote:

Syan,

I don't understand half of what you are talking about. But I appreciate your 
work and reporting.

@all. Is there a way to provide GNUmed with a huge set of patient data.
I am keen on speed tests. I know there is a problem with real patient data. 

>  one problem is that I think if a slow narrative is initiated in one
> patient, and before it returns another patient is selected, garbage
> collection may prevent the next patient being loaded until the thread
> completes , because the thread has a reference to the gmClinicalRecord
> object being garbage collected ( I think ).  I tried making the later part
> of the threaded function keep a weakreference of self ( gmClinicalRecord
> object)  and then checking the weakref  returns self or none  before
> updating self with the retrieved rows, and this seems to keep things
> flowing.  I'd swear that gnumed now is faster then the emr at work for
> browsing a series of patients with really thick medical histories , because
> gnumed doesn't block , (well it won't once the emr journal is also fixed) !
>
>
> On Sat May 27 12:11 , Syan Tan sent:
>
> I got a bit tired of waiting for the narratives to update so took a look
> into emr browser and was able to get multi threaded narrative bulk
> retrieval working.
> When a user selects a narrative node,
> a check is made to see if the cache for narratives is empty,
> if it is a fast query to get the narrative the user selected.
> after that , a thread is started off to get the bulk of the narratives for
> the patient; whenever the user is browsing another narrative, if the
> cache is still not updated, a fast query is done. The thread is only
> started off once, because there is reference to the thread object.
> When the thread gets the narratives in bulk for a patient, it
> constructs the narrative objects, and then with a synchronized access to
> the cache, sets the cache reference for the narratives.
> further user browsing would then get from the cache instead of doing a fast
> query. It could be argued that there is no need to have threading, as the
> user could get only the narratives he views with the fast query.
> the fast query is a modification of v_pat_narratives, which uses
> v_pat_items , and v_pat_episodes, so that the same data is returned in a
> similiar view with similiar names except that on clin.episodes and
> clin.clin_narrative tables are used.
> This avoids sequential scanning of all child tables of clin_root_items,
> which despite experimenting with postgresql.conf , I was unable to turn
> off, and makes v_pat_narratives not useful for fast querying on pk_episode
> keys.
>  In order to get multithreaded ro connection to work, the loginInfo for the
> 'historica' service has to be retrieved from ConnectionPool singleton
> object, and then gmPG.dbapi is used to create a new connection and cursor,
> which can then be passed into gmPG.run_ro_query as the first parameter.
> This allows the slow bulk select to run simultaneously with the
> intermittent fast selects. I encourage anyone interested in emr design to
> take a look at gnumed , as it has some very educational areas in it.

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.gnumed.de]  -> PGP welcome, HTML ->/dev/null
Faire Angebote beim Internetshoppen gibt es in meinem Onlineshop
fairdeal.profiseller.de