String verarbeiten problem

bole · Beiträge: 107 Erhaltene Danke: 15 win 10

Ich arbeite im 3. Level Support eines grossen Finanzdienstleisters... Genau solche Programmierer machen mir das Leben schwehr weil sie für ein einfaches Problem die komplizierteste Lösung programmieren um noch einen Bruchteil einer Mikrosekunde an Performance zu gewinnen!

Solche Programmierung mag zwar sehr interessant sein, jedoch in komerziell genutzten Programmen hat sie meist nichts verloren. KISS heisst das Stichwort (de.wikipedia.org/wiki/KISS-Prinzip)

_________________
ein programm macht nicht das was du willst sondern was du schreibst!

jaenicke · Verfasst: Sa 27.06.09 15:48

Es kommt eben immer drauf an wo man sowas einsetzt. In einer Schleife oder einfach als Befehl. Wie ich ja auch schon geschrieben hatte.

Wenn ich bei meinem aktuellen Problem z.B. einfach mit Strings arbeiten würde ohne mit Pointern zu spielen, dann würde das Auslesen einer 350 MiB Datei mehrere Minuten dauern. Mit Pointern stoße ich jetzt eher ans Limit der Festplattengeschwindigkeit und es dauert ca. 10 Sekunden.
Und bei Dateien "normaler" Größe dauert es nur noch wenige Millisekunden statt mehrerer Sekunden.

Dafür muss man sich eben ganz genau überlegen was man wo tut und kann es nicht wie bei einfacheren Prozeduren einfach herunterschreiben.

MagicRain · Verfasst: Sa 27.06.09 16:57

Also da hat jaenicke nunmal recht hehe! Aber genau das ist es ja am Programmieren für das Problem was man hat genau die richtige lösung zu finden... Nicht immer ist eine bestimmte lösung gut für ein bestimmtest problem

MfG

BenBE · Verfasst: Sa 27.06.09 17:15

Seh ich ähnlich. Generische Algorithmen für spezielle Probleme einsetzen ist mehr als ineffizient und führt oftmals dazu, dass Programme nicht oder nur schlecht skalieren. Das beste Beispiel für solche Fehlentwicklungen sind riesige Webserver wie der Apache, die zwar alles mögliche können, aufgebläht sind, wie Sau, aber nichts optimal können. Vergleicht man dann dem gegenüber den Apache mit dem Gatling, so kann dieser zwar weniger, das was er kann dafür aber so effizient, dass man teilweise nicht merkt, dass er überhaupt etwas tut.

Genauso ist es mit den Funktionen der RTL von Delphi: Diese mögen zwar für alles Mögliche etwas beitragen, um eine Lösung zu erhalten, wenn man dafür jedoch haufenweise Arbeit doppelt ausführt, verschenkt man unter Umständen mehr als "ein paar Millisekunden". Es gibt für mich 3 Dinge, die ich versuche zu vermeiden: 1. Redundanz, 2. Arbeit 3. Aufrufe an den Speicher-Manager.

Die Nutzung der Funktion Insert mag für einzelne Aufgaben durchaus berechtigt sein, sobald sie aber in Schleifen ausgeführt wird, verursacht sie unnötige Aufrufe an den Speichermanager und macht sich durch das Umkopieren der Strings unnötige Arbeit. Wenn man sich also vor der Ausführung einer Routine überlegt, was diese tun soll und was der minimale Weg ist, dies zu erreichen, kann man oftmals zu recht eleganten Lösungen kommen: Man berechne vorher, wie lang das Ergebnis wird und sorge dann dafür, dass man dieses auf dem kürzesten Wege erreicht. Nichts anderes macht meine Routine InsertDashes...

Ich durfte mich auch bereits in historisch gewachsenen (Qualitätsmerkmal 1) und universell eingesetzten (Qualitätsmerkmal 2) Quelltext einarbeiten. Bei einer Datei habe ich nur kurz drüber geschaut, ein Fest für jedes Komprimierungsprogramm und 3 Fehler (die wurden mir bestätigt, dass das wirklich fehler sind) gefunden und nach kurzem Überlegen eine Möglichkeit gefunden, aus ~9kLOC <500 LOC zu machen, ohne dabei an Funktionalität zu verlieren. Nachteilig daran war einzig, dass der Quelltext dadurch ein wenig langsamer geworden ist - das stört aber nicht, wenn dadurch der Wartbarkeitsgewinn dennoch überwiegt.

Mir geht es also weniger um Performance und wie man es am schnellsten anstellt, sondern auch im Wesentlichen um Eleganz. Oftmals spielt beides aber Hand in Hand.

Was mich von daher also am meisten stört, sind Leute, die anhand von Regeln festmachen, ob Quelltext gut oder böse ist: Sicherlich gibt es hier ein paar Regeln, die einem helfen, diesen möglichst gut zu gestalten; aber Regeln sind nun einmal da, um gebrochen zu werden ;-)

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

alzaimar · Verfasst: Sa 27.06.09 18:13

BenBE hat folgendes geschrieben :

Was mich von daher also am meisten stört, sind Leute, die anhand von Regeln festmachen, ob Quelltext gut oder böse ist: Sicherlich gibt es hier ein paar Regeln, die einem helfen, diesen möglichst gut zu gestalten; aber Regeln sind nun einmal da, um gebrochen zu werden ;-)

Verbindliche Regeln sind die einzige Möglichkeit, um einen Haufen von besserwisserischen Egozentrikern (a.k.s. 'Softwareabteilung') auf Linie zu halten. Mit deinen Grundregeln ("Vermeiden von 1. Redundanz, 2. Arbeit 3. Aufrufe an den Speicher-Manager"), wärst Du bei mir gleich wieder vor der Tür(zumindest mit 2 und 3). Aber ich denke, Du bist erfahren genug, selbst deine eigenen Grundregeln ggf. zu brechen. Dazu sind sie ja deiner Meeinung nach gerade da ;-)

. Zudem scheint dein Spezialgebiet genau dort zu liegen, wo diese Regeln Gold wert sind.

Für mich z.B. sind die goldenen Regeln der Softwareentwicklung:
1. Robustheit
2. Einfachheit.
3. Wartbarkeit.

Für so ein kleines Problemchen, wie hier, das zudem von einem 'Anfänger' gestellt wurde, sollte der Code unter Ignorierung sämtlicher Performanceregeln in erster Linie leicht verständlich sein, also z.B. eine direkte Umsetzung einer ersten Problemlösung (Nach 4 Zeichen ein '-' einfügen. Dann -weil ein Zeichen dazugekommen ist- an 9.Stelle, usw). Ob da nun 3x Insert aufgerufen wird, oder nicht, ist irrelevant. Zudem sind die theoretischen Überlegungen bezüglich der Performance seit dem optimierten Speichermanager eh zu überdenken.

Leutchen, hier wollte jemand wissen, wie man einen String überhaupt in Vierergruppen unterteilt, und nicht, wie man das in optimaler Zeit unter Einbeziehung sämtlicher Hacks und Kniffe hinbekommt. Code dieser Art wären auch bein BenBE schnell da, wo sie hingehören (nehme ich an).

_________________
Na denn, dann. Bis dann, denn.

BenBE · Verfasst: Sa 27.06.09 18:40

@alzaimar: Dein letzter Satz ist unverständlich ;-)

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

elundril · Verfasst: Sa 27.06.09 19:03

1) Ich denke gerade hier im Forum, wo es ja nicht direkt um den Einsatz von Code geht, is es schon gut wenn man mehrere Möglichkeiten präsentiert bekommt und ich seh auch nix falsches daran, Codes performancemäßig optimal zu gestalten, denn aus diesen vielen Lösungen kann man sich die, für sich selbst, optimalste Lösung raussuchen bzw durch ein Mash up von zwei lösungen zu einer Optimalen Lösung kommen.

2) was wäre wenn die Insert-Methode mit Pointern usw arbeiten würde, wie BenBe und Jaenicke? Würdet ihr euch dann auch aufregen und ne extra neue Methode machen, weil die von Delphi zur verfügung gestellte "fehleranfällig" ist?

lg elundril

_________________

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

BenBE · Verfasst: Sa 27.06.09 19:39

@alzaimar: Unter Zuhilfenahme eines Thesaurus und der Berücksichtigung des Fuzzy Spellings in deinem Post nehm ich mal an, du meintest, ob bis ans Letzte ausgereizter Code bei mir in der Tonne landen würde:
Ja, wenn er gepflegt werden müsste (verstößt gegen Regel 2: Keine Arbeit machen)
Nein, wenn es darum geht, zu schauen, was möglich ist.
Fall 1 und 2 schließen sich bei mir zumindest aus, weshalb es den Fall "Jain" nicht gibt.

Und zum Thema, dass Code zum Verständnis eines Themas daherrieseln muss, geb ich mal ein Gegenbeispiel, was einige hier sicherlich bereits kennen sollten. Ansonsten Happy Reading ;-)

:
slexy.org/view/s2qBPPzw6Q
Dieser Code ist dabei entstanden, als ein Kumpel mich gefragt hat, wie man mit Pointern arbeitet und wie das ganze funktioniert. Also hab ich mich mit ihm hingesetzt und diesen Clone des Unix-Utilities env geschrieben. Das Teil ist weder effizient, noch übersichtlich, erfüllte abervollkommen seinen Zweck: Wenn man diesen Code verstanden hat, weiß man, wo überall Zeiger einzusetzen sind und weshalb diese zustande kommen. Ist übrigens ein schönes Beispiel, wie wenig viele heute über strikte Typ-Prüfung wissen, bzw. sich drum scheeren. Bei diesem Beispiel kommt es nämlich auf jeden Zeiger an UND dass er an der richtigen Stelle auftaucht. Wenn ich also jemandem erklären möchte, warum man etwas auf eine gewisse Art tun sollte, dann reicht es nicht, eine Trivial-Lösung zu zeigen, sondern man muss denjenigen soweit einbeziehen, dass er auch die Gründe dahinter versteht.

Und für dich zur Beruhigung: Diesen Source würd ich nie in dieser Form schreiben, wenn ich ihn warten müsste. Das Teil ist Unwartbar - auch wenn's beim IOCCC nur den Trostpreis "Nice Try" gewinnen würde. Darf ich jetzt bei Dir anfangen zu arbeiten?

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

bole · Beiträge: 107 Erhaltene Danke: 15 win 10

Zitat:

Ja, wenn er gepflegt werden müsste (verstößt gegen Regel 2: Keine Arbeit machen)

Wenn ich das richtig verstehe behauptest Du Dein Code müsse nicht gepflegt werden. Wahrscheinlich weil er perfekt ist... :shock:

Code pflegen muss man nicht nur wenn Fehler auftreten, es kann auch sein das man das Programm ändern muss sei es durch äussere Einflüsse oder durch eine funktionelle Erweiterung! Solche entwicklungen kannst auch Du nicht vorhersehen...

In hoffe das war ironisch gemeint :wink:

_________________
ein programm macht nicht das was du willst sondern was du schreibst!

Kha · Verfasst: Sa 27.06.09 22:45

BenBE hat folgendes geschrieben :

For-Schleife mit Insert ist dagegen [...] einfach unelegant!

Ich glaube, wir besitzen etwas verschiedene Auffassungen von Eleganz

...

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

import Data.List

blocks :: Int -> [a] -> [[a]]
blocks _     [] = []
blocks width xs = block : blocks width tail
    where (block, tail) = splitAt width xs
    
insertSeperator :: a -> Int -> [a] -> [a]
insertSeperator sep width = intercalate [sep] . blocks width

markieren

Quelltext

1:
2:
3:
4:

ghci> insertSeperator '-' 4 "C92917D2E4D98789EE51928EECA075E8K3NDI45JKS90OMLJD56JLSDJ7LSK6DK"
"C929-17D2-E4D9-8789-EE51-928E-ECA0-75E8-K3ND-I45J-KS90-OMLJ-D56J-LSDJ-7LSK-6DK"
ghci> take 10 $ insertAt 0 1 [1..]
[1,0,2,0,3,0,4,0,5,0]

Wenigstens scheine ich mit delfiphan, alzaimar und bole drei Seelenverwandte zu haben, da kann ich ja heute Nacht beruhigt schlafen :mrgreen:

.

BenBE hat folgendes geschrieben :

ASM ja, Pointer sind dagegen ein warer Genuss. Je kürzer die Anweisung, desto klarer wird sie.

Eben, das ist doch ein Merkmal von "Eleganz", auf das man sich einigen könnte! Bei einer imperativen Sprache wie Delphi werde ich eine deklarative Programmierweise nicht als Merkmal von Eleganz durchsetzen können, aber dass in der Kürze nunmal die Würze liegt, ist quasi allgemein anerkannt:

Zitat:

You've probably seen some variant of this, but I'll show you my version. In coding, you have many dimensions in which you can rate code:

- Brevity of code
- Featurefulness
- Speed of execution
- Time spent coding
- Robustness
- Flexibility

Now, remember, these dimensions are all in opposition to one another. You can spend a three days writing a routine which is really beautiful AND fast, so you've gotten two of your dimensions up, but you've spent THREE DAYS, so the "time spent coding" dimension is WAY down.

So, when is this worth it? How do we make these decisions?

The answer turns out to be very sane, very simple, and also the one nobody, ever, listens to:

"START WITH BREVITY. Increase the other dimensions AS REQUIRED BY TESTING."

Und die kürzeste Delphi-Version stammt ja auch von dir

...
Bei (X and 3) = 0 hoffe ich allerdings, um eine Zusammenarbeit mit dir herumzukommen :mrgreen:

.

jaenicke hat folgendes geschrieben :

Und ist natürlich sehr viel langsamer, also nur geeignet, wenns nur einmal oder so ausgeführt wird. In einer Schleife wäre sowas kaum sinnvoll.

Stimmt, ab zwei Durchläufen wird das schon extrem kritisch...
An der ursprünglichen Frage war schon abzulesen, dass es sich hier wohl nicht um zehntausende Strings handelt. Und wenn I/O noch dazukommt, würde ich keine Aussage über mögliche Bottlenecks wagen, bevor nicht ein Profiler drübergeschickt wurde.
Noch schlimmer: Wenn es beispielsweise ums Transformieren einer Textdatei ginge, ist die Pointer-Version genauso unbenutzbar wie die kürzere Insert-Version - wir wollen schließlich nicht den gesamten String in den Speicher laden müssen, sondern vielmehr Byte für Byte (oder Block für Block) vom Quell- in den Zielstream übersetzen. Ironischerweise schafft das meine Haskell-Version ohne Zutun :zwinker:

. Ich glaube ehrlich gesagt einfach nicht, dass es irgendeinen Use-Case dieser doch relativ speziellen Funktion gibt, der eine Pointer-Version rechtfertigt.

Ich habe natürlich nichts dagegen, wenn auch hyperoptimierte Versionen vorgeschlagen werden, insbesondere wenn der Use-Case nicht klar ist. Aber als in der DP zum Thema "Anzahl Dezimalstellen?" eine Schleifen-Lösung vor der doch wohl "maximal-eleganten" Log-Lösung gepostet wurde, da die FPU eben doch nicht ganz so schnell sei, ist mir nur noch "/facepalm" in den Sinn gekommen

.

Also einfach zusätzlich zum traditionellen Optimisierungswettbewerb noch einen Eleganzwettbewerb in jedem Thread einführen, dann bin ich zufrieden :mrgreen:

.

_________________
>λ=

Missionar · Hält's aus hier Beiträge: 6

Kha hat folgendes geschrieben :

markieren

Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:

import Data.List

blocks :: Int -> [a] -> [[a]]
blocks _     [] = []
blocks width xs = block : blocks width tail
    where (block, tail) = splitAt width xs
    
insertSeperator :: a -> Int -> [a] -> [a]
insertSeperator sep width = intercalate [sep] . blocks width

Kha · Verfasst: So 28.06.09 00:39

Missionar hat folgendes geschrieben :

and friends

Wenigstens kannst du dich nicht mehr beschweren, dass es hier im Forum nur noch um .NET ginge

...

_________________
>λ=

BenBE · Verfasst: So 28.06.09 02:13

bole hat folgendes geschrieben :

Zitat:

Ja, wenn er gepflegt werden müsste (verstößt gegen Regel 2: Keine Arbeit machen)

Wenn ich das richtig verstehe behauptest Du Dein Code müsse nicht gepflegt werden. Wahrscheinlich weil er perfekt ist... :shock:

Nein. Damit meine ich, dass ich Code, der in Real-Programmen auftaucht, die auch Weiterentwickelt werden sollen, nicht bis ins letzte Detail optimieren würde, sondern solche experimentellen Optimierungen auf Testprogramme beschränken, die ich für mich behalte, bzw. die als Demonstration dienen und nicht für den Produktiveinsatz gedacht sind.

bole hat folgendes geschrieben :

Code pflegen muss man nicht nur wenn Fehler auftreten, es kann auch sein das man das Programm ändern muss sei es durch äussere Einflüsse oder durch eine funktionelle Erweiterung! Solche entwicklungen kannst auch Du nicht vorhersehen...

In hoffe das war ironisch gemeint :wink:

Nein, spätestens deshalb nicht, da meine Kristallkugel unter chronischer Belastung durch DAU-Fragen leidet und daher ständig krank feiert ... Aber wie berits angedeutet beschränke ich Optimierungen im Programm auf ein sinnvolles, nebenbei optimierbares Maß: D.h. ich programmier von Haus aus unter Beachtung einiger Regeln zum Schreiben von optimalem Code eine Fassung, an der nicht mehr viel herauszuholen ist (meist) und verschwende keine Zeit darauf, diese noch weiter zu optimieren, außer ich seh: etwas auf anhieb ODER es ist dringend notwendig.

Insofern komme ich selten dahin, dass ich eine Hochoptimierte Routine vorliegen habe, die im Nachhinein optimiert werden muss, da solche Routinen nur in Ausnahmefällen in Produktiv-Software auftauchen.

Kha hat folgendes geschrieben :

BenBE hat folgendes geschrieben :

For-Schleife mit Insert ist dagegen [...] einfach unelegant!

Ich glaube, wir besitzen etwas verschiedene Auffassungen von Eleganz

...

Es ist ein Unterschied, ob das Insert intern die For-Schleife bearbeitet und daher die String-Allocation an einem Stück vorhersehen kann, oder ob ich hunderfach Insert aufrufe und er jedes Mal den String auf's Neue umkopiert.

Kha hat folgendes geschrieben :

Wenigstens scheine ich mit delfiphan, alzaimar und bole drei Seelenverwandte zu haben, da kann ich ja heute Nacht beruhigt schlafen :mrgreen:

.

Wieso? Ich habe nur etwas dagegen, wenn Code offensichtlich sinnlose Arbeit tut ... und das in Schleife ...

Kha hat folgendes geschrieben :

BenBE hat folgendes geschrieben :

ASM ja, Pointer sind dagegen ein warer Genuss. Je kürzer die Anweisung, desto klarer wird sie.

Eben, das ist doch ein Merkmal von "Eleganz", auf das man sich einigen könnte! Bei einer imperativen Sprache wie Delphi werde ich eine deklarative Programmierweise nicht als Merkmal von Eleganz durchsetzen können,

Jap. Daher erübrigt sich dein Vergleich mit Haskell (Wer benutzt sowas esotherisches eigentlich ernsthaft :???:

) ...

Kha hat folgendes geschrieben :

Und die kürzeste Delphi-Version stammt ja auch von dir

...

halt alles eine Frage, wieviele offensichtliche Optimierungen man von Haus aus sieht. Wobei ein wenig geschummelt hab ich da auch, indem ich die Variablen etwas umbenannt hab ;-)

Kha hat folgendes geschrieben :

Bei (X and 3) = 0 hoffe ich allerdings, um eine Zusammenarbeit mit dir herumzukommen :mrgreen:

.

Man könnte theoretisch, unter ganz widrigen Umständen, in einer entfernten, grauen Vergangenheit auch mal X mod 4 = 0 geschrieben haben ... Aber wer macht sowas Hirnrissiges :mrgreen:

Kha hat folgendes geschrieben :

jaenicke hat folgendes geschrieben :

Und ist natürlich sehr viel langsamer, also nur geeignet, wenns nur einmal oder so ausgeführt wird. In einer Schleife wäre sowas kaum sinnvoll.

Stimmt, ab zwei Durchläufen wird das schon extrem kritisch...
An der ursprünglichen Frage war schon abzulesen, dass es sich hier wohl nicht um zehntausende Strings handelt. Und wenn I/O noch dazukommt, würde ich keine Aussage über mögliche Bottlenecks wagen, bevor nicht ein Profiler drübergeschickt wurde.

Wenn I/O dazu kommt, ist es aber oftmals von Vorteil, wenn die I/O-Funktion zum Bottleneck wird ;-)

Der Einsatz eines Profilers ist aber bei jeglichen Aufgaben, wo variable oder undeterministische Verzögerungen auftauchen immer von Vorteil ...

Kha hat folgendes geschrieben :

Noch schlimmer: Wenn es beispielsweise ums Transformieren einer Textdatei ginge, ist die Pointer-Version genauso unbenutzbar wie die kürzere Insert-Version - wir wollen schließlich nicht den gesamten String in den Speicher laden müssen, sondern vielmehr Byte für Byte (oder Block für Block) vom Quell- in den Zielstream übersetzen. Ironischerweise schafft das meine Haskell-Version ohne Zutun :zwinker:

. Ich glaube ehrlich gesagt einfach nicht, dass es irgendeinen Use-Case dieser doch relativ speziellen Funktion gibt, der eine Pointer-Version rechtfertigt.

In der Regel implementiert man aber solche Geschichten, wenn sie für die Verarbeitung von Dateien gedacht sind eh als Stream bzw. als Stream-Filter, weshalb sowas nicht weiter tragisch wäre ...

Kha hat folgendes geschrieben :

Ich habe natürlich nichts dagegen, wenn auch hyperoptimierte Versionen vorgeschlagen werden, insbesondere wenn der Use-Case nicht klar ist. Aber als in der DP zum Thema "Anzahl Dezimalstellen?" eine Schleifen-Lösung vor der doch wohl "maximal-eleganten" Log-Lösung gepostet wurde, da die FPU eben doch nicht ganz so schnell sei, ist mir nur noch "/facepalm" in den Sinn gekommen

.

Wenn ich den ld einer Gleitkomma-Zahl brauch, dann kann es durchaus gerechtfertigt sein, sich den Exponenten direkt aus dem Speicher auszulesen. Sowas wäre aber nur als "Sonder-Lösung für spezielle Fälle" überhaupt im näheren Ideenkreis anzusiedeln. Fällt in Punkt 2 rein: noch hab ich IEEE754 nicht im Kopf; zudem Wartbarkeit ...Wenn verwendet, dann garantiert nicht inline, sondern in einer Funktion ausgelagert ...

Kha hat folgendes geschrieben :

Also einfach zusätzlich zum traditionellen Optimisierungswettbewerb noch einen Eleganzwettbewerb in jedem Thread einführen, dann bin ich zufrieden :mrgreen:

.

k, hätte da glaube ich mal eine Schöne Frage, für die man mal wieder einen wettbewerb starten könnte ... Grob: Jegliche Wörter, die in der deutschen Wikipedia vorkommen alphabethisch sortiert ausgeben ;-)

Aber gut; können wir gern auch für jegliche Anfängerfragen machen

Kha hat folgendes geschrieben :

Missionar hat folgendes geschrieben :

and friends

Wenigstens kannst du dich nicht mehr beschweren, dass es hier im Forum nur noch um .NET ginge

...

Für Haskell gibt es inzwischen auch einen .NET-Compiler AFAIK ...

_________________

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

jaenicke · Verfasst: So 28.06.09 09:21

BenBE hat folgendes geschrieben :

Für Haskell gibt es inzwischen auch einen .NET-Compiler AFAIK ...

Richtig, wie für viele andere Sprachen auch mittlerweile.
Allerdings habe ich noch nie versucht es zu benutzen, das normale Haskell reicht schon.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme