Alias() Angaben gegen Selectbereich [ERLEDIGT]

[andreas]

Ich glaube, dass ich auch meinen Saft dazu geben muss, weil die Änderung auf meinen Vorschlag entstand.

Als ich Manfreds Code gesehen habe, ist mir aufgefallen, dass er zuerst einen Select macht und dann zusätzlich noch bei jedem Feldzugriff die Funktion Alias() aufruft.
Das schien mir, wie auch Tom schon sagte, völlig sinnlos. Warum soll die Funktion jedes Mal aufgerufen werden, wenn in der Klasse die Workarea schon durch eine Variable bekannt ist und dafür verwendet werden kann.
Außerdem muss damit auch Select nicht durchgeführt werden.
Deswegen habe ich Manfred vorgeschlagen, den Code anzupassen. Die Nebenwirkung, die ich mir damit erhofft habe, sollte die Geschwindigkeitsverbesserung sein.
Manfreds Test ergaben leider keine Geschwindigkeitsverbesserung!
Es kann natürlich an unterschiedlichen Faktoren liegen: Hardware, Netzwerk, usw..
Meiner Meinung nach ist es so, dass der sinnlose Code entfernt wurde, was gut ist!
Die Geschwindigkeit könnte evtl. dadurch auch verbessert sein, aber wahrscheinlich so minimal, dass es nicht bemerkbar ist! Das hängt natürlich von der Geschwindigkeit der Befehlsausführung, die in diesem Fall wohl keinen großen Unterschied macht.

[brandelh]

Als ich Manfreds Code gesehen habe, ist mir aufgefallen, dass er zuerst einen Select macht und dann zusätzlich noch bei jedem Feldzugriff die Funktion Alias() aufruft.

das kenne ich doch woher ...

Manfreds Test ergaben leider keine Geschwindigkeitsverbesserung!
Es kann natürlich an unterschiedlichen Faktoren liegen: Hardware, Netzwerk, usw..

ich kann nur betonen, dass meine SSDs einen brachialen Geschwindigkeitsschub bewirkt haben

[Manfred]

@Hubert,

ich habe hier einen Server stehen, der hat SAS Platten verbaut. Bei der Speicherkapazität, die der jetzt hat, wäre es mir viel zu teuer das auf SSD umzurüsten. Da Du aber wohl nur lokal arbeitest, ist es natürlich von Vorteil für Dich, wenn Du auf SSD umrüstest. Es hat aber einen großen Nachteil: Du programmierst nicht für Kunden, die auf normalen System arbeiten und somit bist Du begeistert über das Tempo, da Du ja SSD verbaut hast. Der Kunden hat aber sicherlich noch normales Equipment und da läuft das dann evtl. wesentlich langsamer. Also sollte man schon darauf achten, dass es auf normalem Equipment schnell läuft und dann evtl, auf SSD nochmals schneller. Aber wie schon gesagt, dass dürfte noch nicht der Standard draußen sein.

[brandelh]

Hallo Manfred,

da hast du natürlich Recht
Aber auch ich bedenke, wenn ich was mache, für welches Zielsystem das sein soll (Citrix 10 User würde ich nie einen Filter benutzen, lokal auf SSD spielt das keine Rolle)

Wobei ein SAS im RAID 5 Array auch ganz ordentliche Werte liefern sollte ... das ist vermutlich der Plattencache größer als die Durchschnitts DBF meiner GUI Anwendungen

Lokal habe ich aber eben auch 700 MB++ DBF, die ich mal so eben über einen Filter mit gleichzeitigem Index auswerte ... mit SSD kein Problem.

[Tom]

Es gibt dieses Bonmot vom "free lunch" für Entwickler; Steffen hatte davon beim letzten Forentreffen gesprochen. So lange sich im Halbjahresrhythmus die Hardwareleistung prinzipiell verdoppelte, also zwischen den Neunzigern und dem Ende des ersten Jahrzehnts dieses Jahrtausends, haben sich Fragen der Codeoptimierung oft dadurch erledigt, dass einfach die Hardware sehr viel schneller wurde. Der Geschwindigkeitsgewinn war also quasi kostenlos - free lunch eben.

Trotzdem sollte man Softwareoptimierung und die Verbesserung der Hardwareleistung nicht miteinander verwechseln. Ganz im Gegenteil ist das sogar gefährlich. Wer als Anwender vor einem sehr schneller Rechner sitzt und dann in einer Software mit Latenzen im spürbaren - wenn auch niedrigen - Sekundenbereich leben muss, hält diese Software für langsam (und schlecht). Meistens hat er mit dieser Annahme recht.

[Manfred]

Das ist ja die Gefahr. Es gibt sicherlich Entwickler, die darauf setzen, dass die Hardware schon schnell genug sein wird. Bzw. gab es nicht mal vor gaaanz langer Zeit den Spruch von Billy Boy: macht die Hardware ruhig schneller, wir werden sie schon zu bremsen wissen.... ?

[Jan]

Leider ruhen sich viele Entwickler heutzutage aus. Sowohl was die Performance angeht als auch den Speicherplatz. Beides ist doch in einem unglaublichen Übermaß vorhanden, da muß man sich nicht mehr kümmern.

Sicher muß ich mir heute nicht mehr Gedanken um das letzte irgendwie rauszuquetschende Byte mehr machen wie früher. Wo ich sogar ab und an mal die Zeileninformationen beim Compilieren rausgenommen habe, nur um die exe kleiner zu bekommen, damit die noch auf eine Floppy passte.

Aber wenn ich mir heute manche Software ansehe frage ich mich, wie der Entwickler mit so wenig Funktionsumfang ein solches Bytemonster schaffen konnte. Das ist doch schon alleine Eigennutz, wenn ich das klein schreibe - das macht den Code doch auch gleich viel übersichtlicher (OK, nicht, wenn man das trickst wie Bill Gates, der mit unglaublicher Reduktionen sein Wissen und Genie beweisen wollte, weil niemand sonst den Code mehr lesen konnte). Und natürlich muß man auch bedenken, das nicht jeder User einen i7 mit 16 GB RAM und SSD stehen hat. Bzw. ich ja auch parallel noch andere Programme laufen lassen möchte, ohne das gesamte System auszubremsen.

Sicher kann man heute großzügiger mit Platz und Performance umgehen. Aber aus dem blick sollte man das nie verlieren.

Jan

[Tom]

Sicher kann man heute großzügiger mit Platz und Performance umgehen.

Natürlich. Man sollte sogar gewisse Voraussetzungen formulieren - wer eine moderne Software mit einem Pentium III-Rechner und einer fünfzehn Jahre alten 100-MB-Festplatte nutzen will, sollte sich fragen lassen, ob er überhaupt moderne Software benötigt. Während wir früher schon darüber nachdenken mussten, ob ein komplexer Filter bei einer Tabelle mit 500 Datensätzen noch vergleichsweise hurtig arbeitet, muss und sollte man sich solche Gedanken heute nicht mehr machen. Windows 95/98 hatten begrenzte GDI-Ressourcen; wer mehr als eine bestimmte Anzahl Objekte zu erzeugen versucht hat, erzeugte stattdessen einen Bluescreen. Diese Zeiten sind vorbei. Wenn bei uns ein Kunde anfragt, ob unsere Software auf seinen zwanzig Jahre alten Möhren läuft, fragen wir zurück, wie es denn mit seinem Analogfernseher aussieht.

Trotzdem sollte der Hinweis "Kaufen Sie sich schnellere Hardware" kein Reflex sein, auch wenn das akute Problem damit tatsächlich behoben wäre. Ein komplexer Filter auf verbundenen Tabellen mit Millionen von Datensätzen wird mit einem lokalen SSD-Massenspeicher möglicherweise tatsächlich vergleichsweise zügig antworten. Das ändert nichts daran, dass komplexe Filter auf verbundenen Tabellen mit Millionen von Datensätzen zwar leicht zu programmieren, aber blanker Unsinn sind.