C# Ende eines Arrays erkennen

C# Ende eines Arrays erkennen (76 Beiträge, 730 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo Zusammen,

ihc kämpfe mit folgendem Problem.

Ich will durch ein String-Array iterieren und gewisse characters suchen. Dazu soll nicht irgend eine length Funktion verwendet bzw. erstellt werden.

Mein Ansatz wäre nun, auf Fehler zu prüfen. Sobald ein Fehler auftritt, muss das Ende erreicht sein. Die Frage ist, wie macht man das?

Danke für Eure Antworten.

Eine foreach Schleife?

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

Habe ich mir auch gedacht, wird aber sicherlich nicht als Lösung akzeptiert. Ist für meinen Dozenten ein "no-go"

Absichtlich in eine Exception laufen ist auch ein "no-go"

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

ist es nicht!

bla bla bling bling blow blow bleed bleed bleed bitch

Und der Sinn dahinter?

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

performance...

war mal in einem PerformanceWorkshop da wurde dies als erstes Beispiel genannt!

ich machs selber auch ned... weil so wichtig is mir die Performance dann auch ned.. aber es ist ein gangbarer Weg

EDITH: wobei der PRO in dem Workshop davon gesprochen hat so schnell wie möglich ein Array zu befüllen, und ned auszulesen.. aber das sollt ja kan unterschied machen

bla bla bling bling blow blow bleed bleed bleed bitch

03.03.2010, 20:16 Uhr - Editiert von Entity, alte Version: hier

Hast du zufällig ein kleines Beispiel?

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

ned wirklich....

die frage is auch ab wann sich sowas bemerkbar machen kann...

wie viel kanns denn länger dauern, wenn mans mit for each macht, auf einem PC glaube ich nicht dass es einen unterschied macht! Selbst wenns 2 millisekunden unterschied sind <- drauf ge*PIEP*.

Ich glaub eher dass das auf einem µC sinn machen könnte wenn der leistungsschwach ist und performance wichtig ist.

Aber auf einer noramlen PCCPU wirds nie relevant sein!

um das auf einem PC zu testen müsstest eine RekursiveFunktion machen, die verdammt oft in schleifen arrays befüllt!

Und das ganze zwei mal.. einmal immer mit for each und einmal mit try catch

und wenn das Teil dann einen Tag hackelt, und die eine schleife schneller war als die andere, dann könnte man es sicher brauchbar beurteilen.

Aber das wäre mir zu viel aufwand!

bla bla bling bling blow blow bleed bleed bleed bitch

03.03.2010, 20:35 Uhr - Editiert von Entity, alte Version: hier

Ja das so ein Test etwas Aufwand macht kann ich mir durchaus vorstellen. Daher hat mich interessiert ob du eventuell einen solchen "rumliegen" hast.

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

Ich glaub eher dass das auf einem µC sinn machen könnte wenn der
leistungsschwach ist und performance wichtig ist.

Dann darf man kein .NET, Java und Konsorten verwenden.

Dann darf man kein .NET, Java und Konsorten verwenden.

sag i ja ned

bla bla bling bling blow blow bleed bleed bleed bitch

Das würd ich gern als vernünftigen Benchmark sehen? Ich kenn C# nicht gut genug aber weiß z.B. von Java, dass dort eine Exception massig Zeit kostet, kann mir nicht vorstellen, dass das unter .NET anders sein soll?

In .NET ist eine Exception auch sehr "teuer".

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

Das glaub ich schon und hab ich auch nie bezweifelt. Ich würde nur gern vernünftige Zahlen dafür sehen und hab bezweifelt, dass man diese mit einem Microbenchmark dieser Art bekommt.
Also, hast du Zahlen? Oder worauf basiert deine Aussage?

war mal in einem PerformanceWorkshop da wurde dies als erstes Beispiel
genannt!

Würde mich brennend interessieren, wer so einen Unfug verbreitet, damit ich dann einen großen Bogen um den/diejenigen machen zu können. Gerne auch per PM.

schon länger her.. da hab ich noch studiert...

bla bla bling bling blow blow bleed bleed bleed bitch

Würd mich dennoch brennend interessieren, auch wenns lange her ist

Nicht ernsthaft? Exceptions können in C# sehr teuer werden (Stacktrace aufbauen etc.)

Life is a sexually transmitted disease

Muss es sein, man kann nicht wegen jedem Dreck eine Exception auslösen, sowas zwingt ein System langfristig in die Knie.

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Da sind wir wohl einer Meinung.

http://forum.geizhals.at/t690014,5915703.html#5915703

Dann bin ich wenigstens nicht der einzige auf der Welt der das so sieht.

Exception sind so ziemlich das "teuerste" und daher kann ich mir kaum vorstellen, dass es performanter sein soll eine Exception auszulösen.

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

in einen try catch damit und einfach durchlaufen lassen!

is eine performante variante der Überprüfung

bla bla bling bling blow blow bleed bleed bleed bitch

Danke für die Antwort. Ich werde mich mal schlau machen.

Es geht eben um Performanceberechnungen von Algorithmen...

Das sehe ich nicht so. Ein Exception kostet richtig Performance in .NET

Habs mal kurz getestet:
Variante eins dauerte in meiner VM 4224ms, Variante zwei 29 (!), Variante 3 mit ForEach etwa 35 ms.

var s = new String[] { "Hello", "World", "Test", "Sample" };

            Console.ReadLine();

            var sw = Stopwatch.StartNew();
            for (int i = 0; i < 100000; i++)
            {
                int x = 0;
                try
                {
                    do
                    {
                        s[x].Contains("Hello");
                        x++;
                    } while (true);
                }
                catch (Exception)
                {
                }
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);

            sw = Stopwatch.StartNew();
            for (int i = 0; i < 100000; i++)
            {
                for (int x = 0; x < s.Length - 1; x++)
                {
                    s[x].Contains("Hello");
                }
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);

sw = Stopwatch.StartNew();
            for (int i = 0; i < 100000; i++)
            {
                foreach (var x in s)
                {
                    x.Contains("Hello");
                }
            }
            sw.Stop();
            Console.WriteLine(sw.ElapsedMilliseconds);

Undying

03.03.2010, 23:33 Uhr - Editiert von Undying, alte Version: hier

hmm is anscheinend sprachenabhängig...
wie gesagt ich habs nie getestet. weder in .net noch in einer anderen sprache.

das beispiel wurde aber bei dem Workshop als erstes genannt... ich nehm an in irgendeiner sprache wirds schon so sein. ausser der Lehrer hat das Beispiel nur erfunden

bla bla bling bling blow blow bleed bleed bleed bitch

Nicht in .NET (und das net bitte groß +g+ Microsoft sieht das so garnicht gerne :D)

Undying

Microsoft sieht das so garnicht gerne

also ob die das ned so gern so sehen is mir zeamlich blunzn

bla bla bling bling blow blow bleed bleed bleed bitch

Nicht in .NET (und das net bitte groß +g+ Microsoft sieht das so garnicht
gerne :D)

In PHP kosten Exceptions auch viel Performance. Und AFAIK in Java auch.

04.03.2010, 00:02 Uhr - Editiert von hellbringer, alte Version: hier

Da kann ich nicht mitreden. Bin "nur" ein Microsoft guy.

Da kann ich nicht mitreden. Bin "nur" ein Microsoft guy.

Soso, du hast also auf die dunkle Seite der Macht gewechselt.

schon sehr lange

Wenn es so einfach wäre...Performancemessungen dieser Art haben leider null Aussagekraft, da viele zu viele andere Faktoren (Prozessorlast, Speicherlast, Set Up Time, Hotspots beispielsweise) das Ergebnis zu stark beeinflussen.

naja aber ~4000ms gegen zwei mal grob 40ms san schon a recht deutliches ergebnis.

da geb ich dem undying recht.

interessant wärs wies beispielsweise in c ausschaut!

bla bla bling bling blow blow bleed bleed bleed bitch

interessant wärs wies beispielsweise in c ausschaut!

Da gibt's aber kein exception handling!?

Da gibt's aber kein exception handling!?

sachen gibts.... hab schon seit fast 10 jahren keinen c-code mehr gesehen

bla bla bling bling blow blow bleed bleed bleed bitch

Momentale...

Also angenommen, du bastelst in C ein real-Mode-Programm - dann löst DIV/0 sehr wohl eine Exception aus - die du selbst abfangen kannst.

Unter richtigen Betriebssystemen könntest hingegen zB wissen, dass eine Division durch 0 ein SIGFPE-Signal auslöst.

Das könntest wiederum abfangen - und darauf reagieren...

JA, das ist i.d.R. Schrott (wobei es Anwendungsfälle gibt, wo es Sinn macht, im Notfall auf eine Exception zu reagieren als Trillionen mal den Nenner zu überprüfen, ob er eh nicht in dieser Iteration 0 wird) - aber ausgeschlossen ist Exception-Handling auch in C-Programmen nicht.

Momentale...

Man kann die Sache auch noch allgemeiner sehen.
Aus Java oder .net wird irgendwann Maschinencode, und spätestens da kann man das Verhalten in C nachbilden.

Aus Java oder .net wird irgendwann Maschinencode

Aber mal sicher nicht - ausser an den HotSpots... Zumindest bei Java.

Dann hätte der Prozesor nichts zu tun.

Auch mit einer VM dazwischen hast du letzten Endes etwas in der Muttersprache der CPU. Zwar keine direkte Umsetzung der Programmstruktur, aber trotzdem Maschinencode, der aus den Eingaben die passenden Ausgaben ermittelt.

Deiner Argumentation zufolge gäbe es keinen Interpreter, weil eh alles in Maschinensprache endet... Das wird mir jetzt zu absurd.

Wäre deine Interpretation richtig, dann dürfte es der gleichen Argumentationskette nach auch keine höheren Schichten im OSI-Modell geben.

Moment mal.

Du hast geschrieben "Aus Java oder .net wird irgendwann Maschinencode" - und Java wird _nicht_ kompiliert (HotSpots mal ausgenommen), daher wird _nie_ Maschinencode aus Javacode... Nur die JavaVM ist in Maschinencode...

(HotSpots mal ausgenommen)

Oder JIT, oder AOT

Nur die JavaVM ist in Maschinencode...

Nein. Die VM ist Maschinencode, der eine Bytecode-Instruktion und ihre Argumente nimmt und daraus einen Maschinencode erzeugt, der das entsprechende Ergebnis liefert.
Egal wieviele Abstraktionsebenen du dazwischenlegst oder wann genau Operanden in den Registern landen und eine OP ausgeführt wird, letztenendes ists Maschinencode. Compiliert, interpretiert, Hybridlösungen unterscheiden sich da nur in Nuancen.

Die VM erzeugt keinen Maschinencode (ausser bei HotSpots - wenn JIT aktiviert ist)... Sie _interpretiert_ Bytecode.

Und wenn du behauptest, dass sich Interpreter und Compiler nur in Nuancen unterscheiden - dann hast hiermit bestätigt, dass Du noch nie in deinem Leben einen Compiler oder Interpreter gebaut hast (zumindest garantiert nicht sowohl Compiler als auch Interpreter).

Hmmm... Was sollte als nächstes folgen ? Ich könnte darüber referieren, wie man am besten in der Staatsoper singt und dabei jeden Ton trifft

Sie _interpretiert_ Bytecode.

Und wie macht sie das, ohne Maschinencode zu verwenden, der aus den Eingabedaten die Ausgaben macht?

hast hiermit bestätigt, dass Du noch nie in deinem Leben einen Compiler oder
Interpreter gebaut hast

Alternativ das die scheinbar grossen Unterschiede verschwinden, wenn man das Ganze von ein bisschen weiter weg betrachtet.
Sollte sich seit 1993 herumgesprochen haben, dass der Übergang fliessend ist.

Deswegen in einer VM gemacht die keine Kommunikation nach außen hat. Deswegen 100000 Durchgängen und 3 mal gestartet.
Wennst Unterschiede um Faktor 2 hast kannst es nicht vergleichen. 4000 ms gegen 30 ms ist ein eindeutiges ergebnis und vergleichbar.

Deswegen in einer VM gemacht die keine Kommunikation nach außen hat.

Das ist eine lächerliche Aussage.

Deswegen 100000 Durchgängen

Auch das sagt nix. Weißt du was intern passiert? Weißt du was die VM macht? Weißt du was Garbage Collection bzw. Memory Management machen? Weißt du was geinlined wird? Weißt du inwiefern der erste "Test" die anderen zwei beeinflusst? Weißt du ob die Tests in anderer Reihenfolge nicht andere Ergebnisse bringen? Usw. usw.
Ich glaub auch, dass die Exception Variante die langste der drei ist, wenn ich aber eines in meinen Performance Seminaren gelernt hab ist es das, dass solche Pimperl Programme keinerlei Aussagekraft haben.

EDIT: Außerdem, warum iterierst du in Variante 2 nur bis zu Length-1? Und warum vergleichst du es nicht auch mit einer do/while Variante? Und welche Aussage kannst du treffen, ob nicht das i++ viel langsamer ist als ein optimiertes for? Usw usw

04.03.2010, 00:03 Uhr - Editiert von peter_neugartner, alte Version: hier

Weißt du was Garbage Collection bzw. Memory Management machen? Weißt du was
geinlined wird? Weißt du inwiefern der erste "Test" die anderen zwei
beeinflusst? Weißt du ob die Tests in anderer Reihenfolge nicht andere
Ergebnisse bringen? Usw. usw.

Selten soviel mist gelesen. GarbageCollection läuft erst nach den Schleifendurchgängen. Hier wird viel zu wenig allokiert und CPU Last ist zu hoch.
Optimierungen durch den Compiler kannst ja gerne via Attribute deaktiveren und nochmal messen. Es wird nichts ändern,- und generell sind optimierungen NCIHT schlecht.

Außerdem, warum iterierst du in Variante 2 nur bis zu Length-1?

0 passierender Index

Und welche Aussage kannst du treffen, ob nicht das i++ viel langsamer ist als
ein optimiertes for?

Rat was IEnumerator Interface definiert und was For Each macht.

Sorry aber du lässt nichts als heiße Luft ab. Hier gings nicht um Messungen die 100% der Realtiät entsprechen und wir genau wissen wo 1,5ms gewonnen werden sonderen um einen gernerellen Vergleich. Kernaussage ist lediglich das Exceptions teuer sind.

Selten soviel mist gelesen. GarbageCollection läuft erst nach den
Schleifendurchgängen. Hier wird viel zu wenig allokiert und CPU Last ist zu
hoch.

Ohne dir wirklich die Garbage Collection anzuschaun kannst du absolut keine Aussage dazu treffen.
Hohe CPU Last hat nur minimalen Einfluss auf die Garbage Collection. Gerade wenn du z.B. in eine stop-the-world GC läufst (ohne dass ich jetzt weiß ob/wie das .NET macht) hat die Prozessorlast mal gar nix zu sagen.

und generell sind optimierungen NCIHT schlecht.

Hab ich nirgendwo behauptet und ist damit kein Argument.

0 passierender Index

var s = new String[] { "Hello", "World", "Test", "Sample" };
...
for (int x = 0; x < s.Length - 1; x++)
{
s[x].Contains("Hello");
}
Length == 4
d.h. dein for müsste 0-3 druchlaufen. Da du aber x < s.Length-1 schreibst machst du nur 0-2.

Rat was IEnumerator Interface definiert und was For Each macht.

So what? Das behandelt keinen einzigen meiner Einwände. Und wenn du schon klug*PIEP*en willst, hier mal ein gutes Beispiel wie man sich selber an der Nase herumführen kann: http://diditwith.net/2006/10/05/PerformanceOfForeachVsListForEach.aspx

Und nur der Vollständigkeit halber, ein Artikel zur GC in .NET: http://www.informit.com/guides/content.aspx?g=dotnet&seqNum=786

Und jetzt sag mir dass du immer noch glaubst exakt behaupten zu können, wann die GC bei deinem Programm läuft?

Last but not least ein kurzer Artikel der sich mit Exceptions in micro benchmarks beschäftigt: http://blogs.msdn.com/ricom/archive/2006/09/25/771142.aspx

04.03.2010, 00:37 Uhr - Editiert von peter_neugartner, alte Version: hier

Bei der for Schleife könntest du die Laufvariable vorher deklarieren, bringt auch etwas Performance

Intel i7 920 * DFI LANparty JR X58-T3H6m * Noctua NH-U12P SE2 * 12GB OCZ Platinum * Sapphire HD5850 * 80GB Intel Postville * WD 640GB Caviar Blue * Lian Li A05NB

Undying,

könntest zum Vergleich noch die Abgeänderte V2 laufen lassen:

for (int x = s.Length-1; x >= 0; x--)

In diesem Fall muss s.Length nur einmal pro for schleife evaluiert werden, in dem von dir angegebenen bei jedem Durchlauf. Ich weiß nicht ob der C# Compiler da schon optimiert, beim C Compiler war es aus diesem Grund oft performanter for Schleifen rückwärts zu durchlaufen.

for (int x = s.Length-1; x >= 0; x--)

Deine Schleife hat aber andere Randbedingungen als die von Undying.

Absichtlich, weil ich der Meinung bin daß er mit seinem "< s.Length - 1" um eins zu wenig iteriert. Entweder < ohne -1, oder <= mit -1. Kann aber auch sein daß ich einen Denkfehler hab.

Na gut, zum Vergleichen müßte auch bei mir die Randbedingung falsch gesetzt werden mit x = s.Length-2, Einwand akzeptiert.

Absichtlich, weil ich der Meinung bin daß er mit seinem "< s.Length - 1" um
eins zu wenig iteriert.

Der Meinung bin ich auch aber er hats von oben herab (http://forum.geizhals.at/t690014,5915747.html#5915747 ) als 0 passierenden Index abgetan, trotzdem is es falsch.

Passt, dann sind wir uns einig daß in seiner V2 der "Sample" String nie zu tragen kommt.

Ja, aber das leugnet er wahrscheinlich auch

V2 erscheint mir irgendwie als die logische und schnellste Option, warum sich daher den Krampf der anderen Optionen antun?!? Wenn einer ein Array will, will er ja vermutlich bewußt auf Einzelelemente zugreifen und nicht "ungeordnet" foreach'en. Da gäbe es ja adequatere Typen/Klassen.
Und exceptions - Aua, allein die Idee ist krank.

mfg
lukas

Siehst du, so gehen die Meinungen auseinander. Für mich wär V3 am logischsten. Aber kannst du noch erläutern was an foreach ungeordnet sein soll?

foreach ist nur dann ungeeignet wenn man das durchzusteppende array manipulieren will, da das unzulässig ist.

Muss vorausschicken, dass ich C# nicht spreche, daher eine allgemeine, u.U. unpassende Antwort:

1) foreach würde ich auf ungeordnete Datentypen anwenden (collection, bag...)
2) for 1=0 to XXX würde ich auf Array-ähnliche anwenden, da ja u.U. die Reihenfolge informationsbehaftet ist

Ist aber - wie du sagst - eine Stilfrage!

mg
lukas

foreach iteriert wie aus der MSDN hervorgeht ebenso getreu der Reihenfolge vom ersten bis zum Letzten Element durch, birgt also hier keinen Nachteil.

Das sehe ich nicht so. Ein Exception kostet richtig Performance in .NET

Ich weiß es nur für Java, aber dort ist das genauso. Erstens ist es eben *nicht* performanter, und zweitens, viel wichtiger...

...
catch (Exception) {}

...ist eine völlig hirnlose Vergewaltigung von Exceptions ohne Performance-Vorteil und mit vielen gravierenden Nachteilen. Eine Exception ist eine *Ausnahme* und nicht der *Regelfall* (deswegen sind sie auch langsamer). Zweitens sollten Exceptions möglichst genau abgefangen werden, um verschiedene Fehler verschieben behandeln können (bei Java AFAIR ArrayOutOfBoundsException - wäre hier dennoch völlig fehlplatziert), und drittens, und das ist das gravierendste, werden damit *echte* Fehler kaschiert und unsichtbar gemacht, nachdem der Catchblock leer ist (und das hier auch gar nicht anders geht, weil der Ausnahmefall zum Regelfall gemacht wird). Solchen Kot kann, wer sichs einbildet, in seinem eigenen Häuslprojekt produzieren, wenn er sich dann ausschließlich selbst damit ärgert. Für alles andere ist das eine völlig inakzeptable Vorgehensweise bzw. Codequalität.

05.03.2010, 14:49 Uhr - Editiert von MrT2004, alte Version: hier

Was willst uns damit sagen? Ich hab nur ne Demo laufen lassen bzgl. der Aussage vom Threadopener. Jeder hier weiß, dass das keinen Sinn macht ...

Hier gibt's doch einige (ich will die einzelnen Posts jetzt nicht raussuchen), die sehr wohl der Ansicht sind, dass die Exception-Variante eine legitime und angeblich sogar performantere Lösung wäre. Das ist Unfug, und zwar nicht nur aus Performance-Gründen.

Wen solche und andre Dinge näher interessieren, dem kann ich (für Java halt) "Effective Java" sehr empfehlen, da stehe solche und andre Fehlkonzeptionen gut behandelt drinnen, unter anderem genau diese. Ich wäre ehrlich gesagt nie auf die Idee gekommen, das so zu "lösen".

Wirklich ein String-Array? Also mehrere Strings, und in jedem String nach nem Character suchen?

Oder meinst du ein Character-Array?

Life is a sexually transmitted disease

Dazu soll nicht irgend eine length Funktion verwendet

Wieso nicht? Steht das so in der Aufgabenstellung?

Referenzlösung

http://msdn.microsoft.com/en-us/library/5ts69ce3.aspx

Gibts in diesen mistigen .net Sprachen keinen Iterator?

pong

"Ein Gewitter reinigt die Luft", sagte ein Mann, nachdem ein Blitz seine Frau erschlug

Sicher:
http://msdn.microsoft.com/en-us/library/system.collections.ienumerable.aspx

Dieses Interface wird auch von allen .NET-Collections implementiert.

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung