Häufige Erzeugung eines EventHandler Objekts vermeiden.

Rhombicosidodecahedron

a schrieb:

Rhombicosidodecahedron schrieb:

Das müsste egal sein da es nur um einen einzigen Thread geht, laut doku von SerialPort. Es ist nur das Problem, dass der Thread von SerialPort nicht der ist von der UI.

Die Frage ist, ob für jedes SerialPort-Objekt ein neuer Thread erzeugt wird?
Da kann ich der Doku nicht entnehmen.

Laut .Net Reflector pro jedem SerialPort ein neuer Thread
siehe internal System.IO.Ports.SerialStream.SerialStream(...)

Welche konsequenzen hat das denn genau dafür den Threadersteller?

Rhombicosidodecahedron schrieb:

Welche konsequenzen hat das denn genau dafür den Threadersteller?

Keine.

hustbaer

CSL schrieb:

hustbaer schrieb:

CSL schrieb:

Ja hast du,

aha. was?

Keine "optimierung" wo es nicht nötig ist, da man so Fehler produzieren kann.

Darum geht es in diesem Thread nicht. Der OP wurde bereits (mehrfach) darauf hingewiesen dass Premature Optimization böse ist. Irgendwann reicht's mal. Ob er den Ratschlag beherzigen will liegt nun bei ihm. Es 10x zu wiederholen ist vollkommen sinnlos, nervig und auch äusserst unhöflich.

Bleibt das eigentliche Thema des Threads, und das ist bzw. war wie man es machen kann.

hustbaer schrieb:

du weißt nicht ob es tatsächlich Probleme gibt oder nicht, und wieso ein Risiko eingehen wenn das Ergebnis fragwürdig ist?

ich bin mir sicher dass es keine probleme gibt. die "hab ich was übersehen" frage war 90% aus höflichkeit und 10% weil man nie ausschliessen kann dass man mal "was falsches weiss".

Du zeigst es doch ganz deutlich, so lassen und sicher sein das es funktioniert, oder ändern und die 10% Risiko in kauf nehmen, zu welchem nutzen? Wo es doch nicht einmal gemessen wurde.

Du hast mich falsch verstanden. Ich bin mir wesentlich mehr als nur 90% sicher.
Wenn ich mich danach richten würde was du schreibst, dann könnte ich keinerlei neue Techniken/Frameworks/... einsetzen, weil was ich kann kann ich, und neues dazulernen birgt ja ach so viele Risiken. Ich wünsche dir weiterhin viel Spass beim QBASIC Programmieren.

hustbaer schrieb:

=> Warum ändern (und ein RIsiko eingehen) wenn es so wie es gezeigt wird auf jeden Fall funktioniert?

diese frage steht für micht nicht zur diskussion.

Wieso nicht? Beware of optimizations sagt man nicht ohne Grund.

Siehe oben. 10x reicht.

Mal ganz davon abgesehen dass das ewige "newen" in managed Sprachen eine der grössten Performance-Sünden ist. Eine die viele Programmierer begehen. Und es gibt durchaus Stellen, wo es wirklich viel ausmacht. Sich zu überlegen wie man "new" in bestimmten Konstrukten vermeiden kann, ist daher IMO gut. Dass es in diesem Fall egal ist, ändert nichts daran, dass ansich eine gute und interessante Frage ist.

hustbaer schrieb:

Du stimmst doch zu das man erst messen sollte, sofern das nicht getan ist sollte man nicht einmal darüber nach denken es zu ändern.

völlig am thema vorbei. es wurde behauptet dass es probleme mit thread-safety gibt. ich will jetzt wissen welche, und kein lala warum es eigentlich sowieso gar nicht nötig ist.

Ich habe nie gesagt dass es Probleme gibt, aber es kann, das müsste man heraus finden, dh man müsste Zeit investieren, und man sollte keine Zeit in solchen fragwürdigen Sachen investieren. Es kann auch spätere Fehler provozieren wenn man die Methoden anpassen muss (neuere Features).

Ja, Freund ... siehe oben. Und man kann denke ich auch übervorsichtig sein. Tip: steck deine Tastatur und die Maus ab, dann kannst du weniger Fehler verursachen. Oder noch besser: schalte den PC erst gar nicht ein.

Sobald es gemessen wurde, und festgestellt wurde das es an der Stelle Performance Einbußen gibt, kann man versuchen das Problem an zu gehen, bis dahin besteht kein Problem, hat also absolut kein Handlungsbedarf.

OK, das ist jetzt die ... genau wievielte Wiederholung? 5? 10? 20? Hat wer mitgezählt? Aber natürlich muss ich dir vollkommen Recht geben, war gut dass du es nochmal erwähnt hast.

EXDW

hustbaer schrieb:

CSL schrieb:

Keine "optimierung" wo es nicht nötig ist, da man so Fehler produzieren kann.

Darum geht es in diesem Thread nicht. Der OP wurde bereits (mehrfach) darauf hingewiesen dass Premature Optimization böse ist. Irgendwann reicht's mal. Ob er den Ratschlag beherzigen will liegt nun bei ihm. Es 10x zu wiederholen ist vollkommen sinnlos, nervig und auch äusserst unhöflich.

Bleibt das eigentliche Thema des Threads, und das ist bzw. war wie man es machen kann.

Er beantwortete aber nie ob er überhaupt gemessen hat, warum soll man jemand so etwas helfen wo die Grundvoraussetzungen nicht einmal gegeben sind?

hustbaer schrieb:

Du hast mich falsch verstanden. Ich bin mir wesentlich mehr als nur 90% sicher.

Aber man kann es nicht vollständig sein so lange man es nicht getestet hat, und du weißt auch nicht ob es auch keine Probleme geben wird da du nicht weißt wie der OP es macht. Du weißt auch nicht wie die Methoden noch geändert werden müssen, das weiß nicht mal der OP. Da sind viel zu viele unbekannte als das eine unnütze änderung etwas bringt. Ohne eine Messung kann man es nicht einmal überprüfen nachdem man es gemacht hat.

hustbaer schrieb:

Wenn ich mich danach richten würde was du schreibst, dann könnte ich keinerlei neue Techniken/Frameworks/... einsetzen, weil was ich kann kann ich, und neues dazulernen birgt ja ach so viele Risiken.

Optimierung bedeutet bestehendes zu ändern, wenn eine neue Technologie eingesetzt wird, zb ein neues Framework, hat das auch sein ziel, und so lang dieses nicht erreicht ist, gibt es auch nichts zu optimieren. Optimierung bedeutet ja das man eine bereits bestehende Lösung, derart ändert sodass es besser Skaliert, das hat mit Einführung von neuen Technologien überhaupt nichts zu tun.
Zudem ist bei CCD auch eine tägliche Reflektion ein fester Bestandteil, gerade die CCDler sind offen für Veränderungen

hustbaer schrieb:

Mal ganz davon abgesehen dass das ewige "newen" in managed Sprachen eine der grössten Performance-Sünden ist. Eine die viele Programmierer begehen. Und es gibt durchaus Stellen, wo es wirklich viel ausmacht. Sich zu überlegen wie man "new" in bestimmten Konstrukten vermeiden kann, ist daher IMO gut. Dass es in diesem Fall egal ist, ändert nichts daran, dass ansich eine gute und interessante Frage ist.

In C++ erstellt man auch am laufenden Band neue Objekte, nur eben nicht immer mit den new operator.
Schau mal in jeder x beliebigen C++ Methode rein wie oft variablen erstellt werden, nur weil die in C# immer mit new gemacht werden müssen ist es nicht gleich eine Performance Sünde.
Es ist eher eine Sünde wenn man solche Microoptimierungen auf verdacht ausführt.
Man könnte, wenn man Langeweile hat, auch auch mal anschauen wie der IL Code an der stelle ist, eventuell ist es sogar schon weg optimiert.

hustbaer schrieb:

Ja, Freund ... siehe oben. Und man kann denke ich auch übervorsichtig sein.

Das hat mit übervorsichtig sein nichts zu tun, viel mehr mit Effektivität. Kein Kunde bezahlt für "Features" die keinen Mehrwert haben, es ist nicht einmal ein Refactoring für ein besseres Design, es ist einfach unnütz.

hustbaer schrieb:

... nervig und auch äusserst unhöflich

hustbaer schrieb:

Ich wünsche dir weiterhin viel Spass beim QBASIC Programmieren.

hustbaer schrieb:

Tip: steck deine Tastatur und die Maus ab, dann kannst du weniger Fehler verursachen. Oder noch besser: schalte den PC erst gar nicht ein.

Fass dir erst einmal an die eigene Nase.

hustbaer

@CSL
Wieso sollte der OP jede Frage beantworten die man ihm stellt? Und du musst ja nicht helfen, lass es halt einfach, zwingt dich keiner. Bloss spam nicht sinnlos rum mit "guten Ratschlägen" die seine Frage nicht beantworten.

Stellst du dich auch vor nen Juweliergeschäft und erzählst den Leuten die da reingehen allen dass sie so unnützen Kram eh nicht brauchen und das Geld lieber für was sinnvolleres einsetzen sollten?

Optimierung bedeutet bestehendes zu ändern

Vielleicht im engsten Sinn des Wortes. Man kann Code auch gleich "optimiert" schreiben, dann ändert man nichts bestehendes.

Zudem ist bei CCD

CCD?

Schau mal in jeder x beliebigen C++ Methode rein wie oft variablen erstellt werden, nur weil die in C# immer mit new gemacht werden müssen ist es nicht gleich eine Performance Sünde.

Dann hast du da was grundlegend nicht verstanden. Stack = gratis, new = nicht gratis.

Es ist eher eine Sünde wenn man solche Microoptimierungen auf verdacht ausführt.

Sehe ich nicht so.

Man könnte, wenn man Langeweile hat, auch auch mal anschauen wie der IL Code an der stelle ist, eventuell ist es sogar schon weg optimiert.

Nein, ist er nicht. Kann ich dir sagen ohne den Code angesehen zu haben. Ja, ehrlich. (kann er nämlich gar nicht sein)

Fass dir erst einmal an die eigene Nase.

Ich hab mit dem Scheiss hier nicht angefangen

Firefighter

Man muss doch nicht immer gleich so ausfallend und arrogant werden hustbaer. Die Qualität deiner Posts war auch schon mal besser gewesen, aber jetzt muss man immer damit rechnen das man direkt vollgemault wird.

Jockelx

Naja, ich fand es auch extrem seltsam, warum auf eine im Prinzip so einfache und klare Frage erst mitte der zweiten Seite ein Lösungsvorschlag kam.
Und vorher nur: Hat dich nicht zu interessieren wie es ggf. besser geht, solange du keine Performance-Probleme hast.

EXDW

hustbaer schrieb:

Wieso sollte der OP jede Frage beantworten die man ihm stellt?

Wenn er passende antworten möchte, dann ja.

hustbaer schrieb:

Und du musst ja nicht helfen, lass es halt einfach, zwingt dich keiner. Bloss spam nicht sinnlos rum mit "guten Ratschlägen" die seine Frage nicht beantworten.

Ich bin nicht der einzige ;), siehe ende meine Postings.

hustbaer schrieb:

Stellst du dich auch vor nen Juweliergeschäft und erzählst den Leuten die da reingehen allen dass sie so unnützen Kram eh nicht brauchen und das Geld lieber für was sinnvolleres einsetzen sollten?

Schlechter vergleich.
Bei einem Juwelier bezahlt der Kunde diese Ware auch, der Kunde bezahlt aber nichts was er nicht sieht und was ihn nichts bringt.

hustbaer schrieb:

Vielleicht im engsten Sinn des Wortes. Man kann Code auch gleich "optimiert" schreiben, dann ändert man nichts bestehendes.

Du bringst da etwas durcheinander, Optimieren bedeutet doch das man bereits etwas bestehendes hat, der OP hat auch schon bestehenden Code, wenn man von Grund auf etwas schreibt welches gut Skaliert, hat das mit Optimierung nichts zu tun.

hustbaer schrieb:

CCD?

www.clean-code-developer.de

hustbaer schrieb:

Ich hab mit dem Scheiss hier nicht angefangen

Ich weiß ich sollte mich auf diesen Kindergarten kram "Du hast angefangen" nicht einlassen, aber:

theta schrieb:

Und woher weisst Du, dass es ineffizient ist?

theta schrieb:

Tja, Du denkst es ist ineffizient... miss es oder lass es. Ausserdem tust Du das nur dann wenn Du ein Performance Problem hast.

chrische5 schrieb:

Wenn du nicht weißt, ob es welche verursacht, ist das alles Kaffeesatzleserei. Du musst es messen. Am besten macht man Performanceverbesserungen eh erst am Ende. Mach es lauffähig, schau, ob der Speed passt. Wenn ja -> alles gut. Wenn nicht -> Profiler und kritische Stellen anschauen und dann dort optimieren.

loks schrieb:

Auch wenn es ein abgedroschener Schuh ist... Das was Du da machst hat einen Namen: "Premature Optimizing" und ist zu recht eines der Anti-Patterns. Daher gibt es auch einen ganz einfachen Merksatz: Premature Optimizing - Dont do it.

Die eigendlich Regel lautet: First make it run, than make it fast. Alles andere kostet nur unnötige Zeit und bringt in den wenigsten Fällen was. Woher willst Du denn z.B. wissen ob der andere Ansatz tatsächlich performanter ist?

ich kam erst später dazu, und Beleidigungen kamen bisher nur von dir.

EXDW

@Jockelx:

Das liegt einfach daran da manche menschen, einsteigern (-com- ist ja einer nach eigenen angaben), nicht gleich Bullshit bei bringen will, sodass er glaub solche "Optimierungen" würden etwas bringen.

Manche von uns haben Prinzipien.

Einsteiger halten sich viel zu lange mit derart Kleinkram auf statt tatsächlich zu lernen.

Dravere

@CSL & hustbaer,
Für einen Streit braucht es immer zwei, es ist völlig egal wer angefangen hat. Aber die Diskussion wäre doch eigentlich noch ganz interessant, lasst doch einfach die Sticheleien am Ende jeweils weg. Ich möchte den Thread nicht unbedingt geschlossen sehen

Ich bin übrigens der Meinung, dass ihr beide recht habt. Viele Anfänger halten sich mit solchem Kleinkram viel zu lange auf. Ich habe diese Erfahrung selber gemacht damals in C++. Also sollte man dies dem Anfänger ganz klar sagen. Nicht desto trotz kann man doch einfach rein theoretisch über Möglichkeiten zur Optimierung diskutieren und allenfalls Vorschläge reinbringen.

Grüssli

EXDW

Das kann ich so unterschreiben Gutes Schluss Plädoyer.

Ich denke nicht das dieser Thread noch sinnvoll fort gesetzt werden kann, das [neue] Thema ist eigentlich durch.

EXDW

Was ich noch anmerken wollte, ist mir in einem Projekt selber auch schon passiert.
Man kann nicht Pauschal alle Properties die man einem Invoke übergibt über Members lösen, da Invoke asynchron läuft kann es sein der der erneute Aufruf den Member ändert und sobald das Invoke ausgeführt wird ist es schon zu spät, dh es kann an der stelle zu Datenverlust kommen.

Ich hatte es selber bei einem BackgroundWorker, ich dachte ich sei schlau und habe ein ***EventArgs Objekt zu dem Member gemacht, da ich dachte "zuviel Erstellung kann vermieden werden" (~3000x / Sekunde).
Nun war es so das dieses ***EventArgs Objekt eine Liste von Objekten enthielt welches in der UI dann angezeigt werden sollten.
Leider lief das zu schnell sodass die Liste in den ***EventArgs wieder geleert wurde noch bevor das Event in der UI überhaupt bearbeitet wurde.

Durch Erzeugung der neuen Objekten war es dann sicher gestellt da nur eine neue Referenz zugewiesen wurde und das Event in der UI noch die alte hielt, das konnte dann Collected werden sobald die UI das Event abgearbeitet hatte.

Das hat ziemlich deutlich gezeigt, auf den ersten Blick absolut trivial und verständlich, aber durch das Asynchrone hatte man Seiteneffekte.
Und Performance Einbußen habe ich von den 3000x new auch nicht.

hustbaer

Du bringst da etwas durcheinander, Optimieren bedeutet doch das man bereits etwas bestehendes hat, der OP hat auch schon bestehenden Code, wenn man von Grund auf etwas schreibt welches gut Skaliert, hat das mit Optimierung nichts zu tun.

Deswegen hab' ich geschrieben "Vielleicht im engsten Sinn des Wortes."
Ich lege das eben etwas weiter aus.
Ich kann z.B. auch meinen Programmierstil "optimieren", indem ich mir bestimmte - neue - Techniken aneigne. z.B. Techniken, wie man bestimmte Dinge halbwegs elegand und performant erledigen kann.
Oftmals ist das sicher unnütz weil verschwendete Zeit & Energie. Andere Dinge gibt es aber, die man - wie ich finde - schon wissen "darf". Und dazu gehört IMO auch wie man "new" vermeiden kann wenn es an einer bestimmten Stelle Sinn macht.

ich kam erst später dazu, und Beleidigungen kamen bisher nur von dir.

Du hast nicht mit direkten Beleidigungen oder Sarkasmus angefangen, das ist vollkommen richtig.

Lass mich vielleicht erklären wieso ich hier (wiedermal :() etwas ausgeflippt bin.
Ich lese diesen Thread. Dabei hab' ich übersehen dass der OP bereits ganz zu Anfang selbst die Membervariablen-Variante (eine IMO vollkommen naheliegende und auch sichere Lösung das "new" zu vermeiden) vorgeschlagen hat (sonst hätte ich ihn einfach nur mit "ja, das geht so" bestätigt statt es als "meine Idee" zu verkaufen).
Ich sehe weiters dass noch keine Antwort auf seine eigentliche Frage gekommen ist (vielleicht war eine vor meinem Beitrag die ich auch überlesen habe - mag das jetzt nicht gegenchecken). Sondern nur wiederholt der Hinweis dass die Optimierung doch eh fürn Hugo ist.
Grundsätzlich richtig, aber man kann auch etwas zu sehr darauf rumreiten wie ich finde. Vor allem wenn die eigentliche Frage einfach zu beantworten ist.
Ich halte mich also schon soweit zurück nicht in meinen ersten Beitrag zu schreiben, dass ich es etwas befremdlich finde, wie hier eine Frage ignoriert wird, und stattdessen (unerbetene) "gute Ratschläge" kommen. Und das nicht nur ein oder zwei mal, sondern massivst.

Und darauf hin schreibst du *MIR* den selben guten Ratschlag. Und da is mir einfach der Knopf aufgegangen. Darf man jetzt nichtmal ne Frage beantworten, ohne gleich von jmd. belehrt zu werden? Mir ist vollkommen klar dass es in dem speziellen Fall vermutlich eine sinnlose Optimierung ist. Trotzdem finde ich darf man ja noch die Frage beantworten.

Das meinte ich auch mit "du hast angefangen": du hast die Diskussion über Sinn oder Unsinn dieser Optimierung mit *mir* angefangen. Ich wollte die eigentlich gar nicht führen, ich wollte nur eine Frage beantworten.

----

Vielleicht hab' ich das nicht deutlich genug geschrieben: ich stimme grundsätzlich mir dir überein, dass Premature Optimization böse ist. Ich schreibe das auch selbst oft hier im Forum.
Wo wir vielleicht anderer Meinung sind: ich empfinde es nicht als Zeitverschwendung, sich über gewisse Dinge Gedanken zu machen, und gewisse Techniken zu lernen. Auch wenn man sie an der Stelle wo man sie erlernt gar nicht gebraucht hätte.
Und wie gesagt: das ewige "new" in managed Sprachen ist IMO eine Seuche. Und es gibt definitiv Stellen wo es auffällt. Viele Objekte sind ausreichend klein, und auch die von dir erwähnten 3000 Calls/sec. sind relativ wenig. Das macht noch kein Problem.
Aber mach das mal in einer engen Schleife, und vielleicht mit grösseren Objekten. Dann merkst du den Unterschied gleich.

hustbaer

Und was das EventArgs Beispiel angeht...

Einen Anfänger hätte es hier vermutlich auch nicht gerettet, wenn er auf Optimierungen verzichtet hätte, denn der IMO naivste Weg sowas zu machen ist:

class Foo
{
    void MyThread()
    {
        while (...)
        {
           // do some stuff, modify m_list and/or the objects referenced in it
           do_some_stuff();

           something.BeginInvoke(new SomeDelegate(Target), new SomeEventArgs(m_list));
        }
    }

    List<Stuff> m_list;
}

class SomeEventArgs
{
    public SomeEventArgs(List<Stuff> list)
    {
        List = list; // just referencing the list, no copy!
    }
    public List<Stuff> List;
}

Das fliegt dir dann genauso um die Ohren.

Damit es nicht knallt, muss man die Liste kopieren, und u.U. sogar die darin referenzierten Objekte.

Das Erstellen des Delegate kann man dagegen problemlos in den ctor verlagen, denn den Delegate ändert man ja nicht mehr (kann man auch gar nicht, da .NET Delegates genauso wie .NET Strings immutable sind).

BTW: du meinst vermutlich Control.BeginInvoke. Control.Invoke ist synchron