Geht´s nicht ein bisschen schneller?

Allgemein, sozusagen "streng nach Lehrbuch" gilt die Devise in der Softwareentwicklung, dass übersichtlicher, gut zu wartender Programmcode Vorrang gegenüber Programmiertricks haben soll, um das Maximum an Arbeitsgeschwindigkeit herauszukitzeln. Tricks, die niemand außer dem eigentlichen Programmierer versteht - und sogar dieser selbst ein paar Jahre später vielleicht nicht mehr. Man geht einmal davon aus, dass die stetig voranschreitende Entwicklung bei der Hardware das Problem ohnehin von selbst entschärfen wird.

Wie alle anderen Softwareprodukte sind davon natürlich auch Laborinformationssysteme (LIMS) betroffen und soweit wie möglich, halten wir uns an diese Regel. Bisweilen kommt es aber doch vor, dass der Anwender mit der Abfragegeschwindigkeit nicht ganz zufrieden ist. Klar, in unserer Zeit ist man schon nervös, wenn man eine Minute vor der roten Ampel stehen muss, wo doch der Tag voller Termine ist.

Meistens tritt das Problem klarerweise nicht sofort nach Inbetriebnahme des LIMS auf, sondern erst, wenn es mit mehr oder weniger umfangreichen Daten gefüllt ist - und es sich zeigt, dass der Mehraufwand der Abfragen doch nicht ganz durch die technische Weiterentwicklung kompensiert werden kann. Hier wird dann doch öfters gebeten, ob man hier nicht etwas verbessern kann.

In manchen Fällen lässt sich durch Optimierung der Datenbank viel erreichen, aber leider nicht immer. Ein ganz "klassisches" Beispiel ist die Erstellung von Statistiken, zum Beispiel eine Aufstellung, welche Parameter wie oft in den einzelnen Monaten untersucht wurden. Der einfachste und übersichtlichste Weg der Programierung ist, dass das LIMS für jeden Parameter und jede Periode (also z.B. Monat) einzeln die Anzahl der Bestimmungen abfragt. Bei z.B. 200 Parametern und 12 Monaten also 2.400 einzelne Abfragen, was unter Umständen schon einige Zeit in Anspruch nehmen kann.

Hier gibt er aber eine viel effizientere Lösung, indem man eine Abfrage über alle Parameter und das ganze Jahr startet und die Ergebnisse dieser (nur einen!) Abfrage dann quasi in ein Raster "einsortiert", am besten mit einer "Strichliste" für die Kaffeekassa zu vergleichen.

In dieser und vielen anderen Situationen kann man also durch geschickte Umprogrammierung sehr viel an Performancezugewinn erreichen. Nur darf man nicht vergessen, dass - was leider manchmal nicht allen Anwendern klar ist - es sich praktisch um eine Neuprogrammierung handelt, die genauso gründlich getestet werden muss wie eine komplett neue Funktion.

< Früherer Beitrag