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

[Syan Tan]

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.