Horst Herb wrote:
> Now, when I choose a drug to prescribe or a patient, I will choose from a pick list
>("combo box" type). Both in case of patients and drugs I will select from several
>tens of thousands of values. The pick list has to show alternatives from the second
>letter entered already for resons I'll explain later - that usually leaves a _lot_ of
>possible entries. Of course, everything has to appear instantly on the screen.
I had a similar problem with the need to be able to display lots of 20 or so company
names from a list of around 5000, and the user had to be able to jump anywhere in the
list instantly.
> Solution attempt: the transaction server will (in a background thread) select the
>possible entries ( as defined by the first two or more letters) in packs of 15-30 and
>pass them to the front end in order to add them to the list. As memory is still a
>scarce ressource and is not to be wasted, the pick list is based on a indexed linked
>list of a few hundred entries, where the already browsed-through items are released
>(overwritten) after a certain threshold already been browsed through. That way
This number already tells me you are operating a factor of 10 - 100 slower than a
system I worked on, which was: Eiffel (about the same performance as C++, maybe 10%
slower), including WEL library (MFC wrapper, providing access to the combo boxes) +
Matisse object database. OS = NT 4.0; Hardware = Pentium II 200 MHz server; 10 mbit
network. I initially thought to bring back small numbers of keys. Another engineer
convinced me to set the buffering to the max, and get the lot. So I did. It took less
than 5 seconds to populate the whole thing (5000 x 40 character names).
I never bothered to try to optimise any of the dozen things I could have.... but the
main factor was clearly the object database. It was far faster than other departmental
databases (Sybase on high-end HP servers) for anything for which we could make a
reasonable comparison.
> (BTW, can you see what would happen if I would use Java or a web applet here? Maybe
>pepped up by two more abstraction layers? Interrupted by some unpredictable garbage
>collector? (Everything would be slower*10 - just using a ODBC or JDBC driver almost
>doubles the response times!))
Eiffel uses an incremental garbage collector. We never noticed it was on (i.e. we
turned it off to see how things ran, and couldn't tell the difference).
> If you have a patent solution for these ultra-long pick lists, please let me know.
I suggest you consider a faster underlying database. It is almost certainly the slow
part of your system. But I agree this is a problem in health, and I expect to have to
think a bit harder to deal properly with it in the future, especially the soundalike
problem.
- thomas beale
