C# C# Performance langsam

Danke nochmal für die Idee mit dem Thread, damit komme ich nun auf 60 millionen Ticks die Sekunde :)
 
soul0ry schrieb:
Danke nochmal für die Idee mit dem Thread, damit komme ich nun auf 60 millionen Ticks die Sekunde :)

Hier mal ein (ungetesteter) Vorschlag:

PHP:
class Program
    {

        static void Main(string[] args)
        {
            new Program
            {
                inputstring = "test",
            }.Run();
        }

        String inputstring = "";
        long curtime;
        String curstring = " ";
        char curchar;
        int charint = 0;
        int maxpos = 0;
        int count = 0;
        static long last;

        class UpdateUiEventArgs : EventArgs
        {
            public string CurrentValue { get; set; }
        }

        event EventHandler UpdateUi;

        public void Run()
        {
            UpdateUi += (sender, args) =>
            {
                // TODO hier Label aktualisieren mit args.CurrentValue
                // myLabel.Text = ((UpdateUiEventArgs) args).CurrentValue;
            };

            new Thread(() =>
            {
                while (true)
                {
                    UpdateUi.Invoke(this, new UpdateUiEventArgs { CurrentValue = curstring });
                    Thread.Sleep(100);
                }
            }).Start();

            last = Environment.TickCount / 1000;
            while (!curstring.Equals(inputstring))
            {
                charint++;
                count++;
                curchar = (char)charint;
                if (count % 10000 == 0)
                {
                    Console.WriteLine("Iterations:" + count);
                    Console.WriteLine("Iterations/s: " + ((float)count / ((float)curtime)));
                    Console.WriteLine("Time: " + ((float)curtime));
                }
                long newlast = Environment.TickCount / 1000; ;
                long dif = newlast - last;
                curtime += dif;
                last = newlast;
                char[] chararray = curstring.ToCharArray();
                if (charint >= 255)
                {
                    charint = 0;
                    int bufpos = 0;
                    while (bufpos < chararray.Length)
                    {
                        for (int i = 0; i < bufpos; i++)
                        {
                            chararray[bufpos] = (char)0;
                        }
                        if (bufpos == maxpos)
                        {
                            maxpos++;
                            char[] buffer = new char[chararray.Length + 1];
                            for (int i = 0; i < buffer.Length; i++)
                            {
                                buffer[i] = (char)0;
                            }
                            chararray = buffer;
                        }
                        if (chararray.Length > bufpos + 1)
                        {
                            int x = (int)chararray[bufpos + 1];
                            x++;
                            chararray[bufpos + 1] = (char)x;
                            if (!(x > 255))
                            {
                                break;
                            }
                        }
                        bufpos++;
                    }
                }
                chararray[0] = curchar;
                curstring = new string(chararray);
                //Console.WriteLine(curstring);
            }
            Console.WriteLine("Start");
        }
    }
 
Seh das Problem auch eher in der Art und Weise, wie du die UI updatest.

Code:
public void SetText(string text, TextBox box)
    {
      if (box.InvokeRequired)
        box.Invoke( ... );
      else
        box.Text = text;
    }

1. Kannst du dir das if hier sparen, da InvokeRequired immer true ist (du updatest von einem anderen Thread).
2. Invoke blockiert den Thread bis der Text geupdated wurde. BeginInvoke wäre hier die bessere Wahl.
 
60 Millionen pro Sekunde kommt mir ein wenig viel vor. Bist du dir sicher, dass die Ausgabe stimmt?
 
mit der Konsolenanwendung komme ich sogar über 100millionen Ticks die sekunde, sehr gut ;)
@Turas:
Es stimmt, 100 millionen ist ein guter Wert für ein offline Brute-Force Programm(siehe hier)
Leider gehen in dem Programm nur maximal 4 stellige passwörter, diesen bug habe ich nur in meinem c++ Programm gefixed ;)
@holy:
Das dürfte nicht allzu viel machen, vorallem wenn es nur den update-Thread blockt, aber ich werde es mir für die Zukunft merken, danke.
 
Zuletzt bearbeitet von einem Moderator:
Und er findet auch verschiedene Strings?

Edit: 100 Mio Tests pro Sekunde würde bedeutet, dass du nur 30 CPU Zyklen pro Stringvergleich brauchst o.O
 
Verwende mal bitte eine Stopwatch für die Zeitmessung.
100 mio. ist doch etwas viel. Und bzw. Environment.TickCount liegt zwischen int.MinValue und int.MaxValue. D.h. es kann auch negativ sein, dies würde deine Anzeige verfälschen.
 
Stimmt, leider habe ich mich um eine Stelle verzählt (zu große Zahlen für mich), es sind nur 10 millionen, aber immer noch ein gutes Ergebnis.
 
soul0ry schrieb:
Stimmt, leider habe ich mich um eine Stelle verzählt (zu große Zahlen für mich), es sind nur 10 millionen, aber immer noch ein gutes Ergebnis.
Tja, der Teufel steckt im Detail :-) Aber ich finds sehr positiv, dass Du da direkt erkannt hast, dass hier was nicht stimmen kann. Das tun viele, auch professionelle Leute, nicht mehr.

Gibt leider zu viele Leute, die bei solchen Performance-Issues direkt hergehen, C oder was-weiß-ich in den Himmel loben und dann wieder über die Performance von solchen Sprachen wie C# und Java herziehen, ohne überhaupt in Erwägung zu ziehen, dass hier irgendwo eine Leiche vergraben ist. Klar kann maschinennahe Programmierung immer etwas schneller sein, aber die Hauptperformance-Killer in modernen Anwendungen liegen einfach zu 95% darin vergraben, dass man heute mit den ganzen tollen Bibliotheken so viel so einfach tun kann, und sich gar keine Gedanken mehr darüber macht, was I/O in einer Schleife eigentlich bedeutet.
 
Zuletzt bearbeitet:
@captmcneil:
Ich habe nie gesagt dass C# schlecht ist, ich wusste, dass es ein Fehler meinerseits sein musste (da java ja auch mit genug t/s lief).
Gerade dank dem JIT-Compiler ist es gut möglich, dass C#/Java schneller läuft als C++.
 
soul0ry schrieb:
@captmcneil:
Ich habe nie gesagt dass C# schlecht ist, ich wusste, dass es ein Fehler meinerseits sein musste (da java ja auch mit genug t/s lief).
Gerade dank dem JIT-Compiler ist es gut möglich, dass C#/Java schneller läuft als C++.
Jo, kein Vorwurf, im Gegenteil. Ich sehe nur nach wie vor sehr viele Leute, auch junge, die das nicht so sehen können.
 
soul0ry schrieb:
@holy:
Das dürfte nicht allzu viel machen, vorallem wenn es nur den update-Thread blockt, aber ich werde es mir für die Zukunft merken, danke.

Auch wenn es mittlerweile egal ist.. Die Art und Weise, wie du es implementiert hast, hat aber den Worker-Thread geblockt. Erst jetzt updatest du auf einem eigenen Thread.
 
captmcneil schrieb:
Gibt leider zu viele Leute, die bei solchen Performance-Issues direkt hergehen, C oder was-weiß-ich in den Himmel loben und dann wieder über die Performance von solchen Sprachen wie C# und Java herziehen, ohne überhaupt in Erwägung zu ziehen, dass hier irgendwo eine Leiche vergraben ist. Klar kann maschinennahe Programmierung immer etwas schneller sein, aber die Hauptperformance-Killer in modernen Anwendungen liegen einfach zu 95% darin vergraben, dass man heute mit den ganzen tollen Bibliotheken so viel so einfach tun kann, und sich gar keine Gedanken mehr darüber macht, was I/O in einer Schleife eigentlich bedeutet.

Natürlich kann man seinen Code oft noch optimieren, aber C ist in den meisten Fällen einfach sehr viel schneller. Gerade was Schleifen und mathematische Operationen angeht. In diesem speziellen Fall würde C wahrscheinlich extrem viel schneller sein.
Da ich ungern auf den Komfort von Sprachen wie C# und der Entwicklungsumgebung Visual Studio verzichte, lager ich Funktionen die sehr Berechnungsintensiv sind in C-DLLs aus. Das ist sehr effektiv.
 
Naja, das kannst du in Java ebenso tun. Ob das sinnvoll ist, sei mal dahingestellt, denn das läuft ja gegen das Kernkonzept - write once, run anywhere.
Gibt noch ein paar Spielereien wie Unsafe usw.
 
Zurück
Oben