Häufige Erzeugung eines EventHandler Objekts vermeiden.

[Rhombicosidodecahedron@of]

-com- schrieb:

Rhombicosidodecahedron schrieb:

Dann tu das doch !?!

Wenn ich wüßte, wie ich das deklarieren soll, hätte ich nicht diesen Thread gestartet.
Ich kenne von C und C++ Funktionszeiger, aber hier gibts ja diese Delegaten.

Rhombicosidodecahedron schrieb:

P.S.: Musst du bei Invoke nichtz auch noch Argumente übergeben?

Zurzeit noch nicht, d.h. die Daten werden von einem Objekt empfangen, das kein UI-Objekt ist.

Wie eine Normale Memberdeklaration.

[Gast]

Hallo

-com- schrieb:

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.

Ich möchte erst gar keine Performanceprobleme riskieren, zumal sie sich mit ein paar wenigen Codezeilen von vornherein vermeiden lassen.

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.

Das hat sich. zumindest bei mir, so bewährt.

chrische

[loks]

-com- schrieb:

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.

Ich möchte erst gar keine Performanceprobleme riskieren, zumal sie sich mit ein paar wenigen Codezeilen von vornherein vermeiden lassen.

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?

Hinzu kommt das der Ansatz mit dem new thread save ist weil praktisch in jedem Thread ein eigenes Handle-Objekt erzeugt wird -> kein locking notwendig. Wenn Du agegen ein zentrales Objekt verwendest mußt Du eventuell auch locking benutzen um race-conditions zu vermeiden... Ob das dann wirklich schneller ist?

[Rhombicosidodecahedron]

loks schrieb:

Hinzu kommt das der Ansatz mit dem new thread save ist weil praktisch in jedem Thread ein eigenes Handle-Objekt erzeugt wird -> kein locking notwendig. Wenn Du agegen ein zentrales Objekt verwendest mußt Du eventuell auch locking benutzen um race-conditions zu vermeiden... Ob das dann wirklich schneller ist?

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.
Wobei vielleciht als alternative wäre, wenn die Funktion > 10 Mal pro Sekunde aufgerufen wird, dann sollte die UI über einen Timer alle 250ms den Text über einen Cache abfragen und nicht umgekehrt, sonst flackert es sehr wahrscheinlich.

[SolidOffline]

-com- schrieb:

Rhombicosidodecahedron schrieb:

Dann tu das doch !?!

Wenn ich wüßte, wie ich das deklarieren soll, hätte ich nicht diesen Thread gestartet.
Ich kenne von C und C++ Funktionszeiger, aber hier gibts ja diese Delegaten.

Rhombicosidodecahedron schrieb:

P.S.: Musst du bei Invoke nichtz auch noch Argumente übergeben?

Zurzeit noch nicht, d.h. die Daten werden von einem Objekt empfangen, das kein UI-Objekt ist.

private EventHandler DisplayHandler;

... im Konstruktor ...

DisplayHandler = DisplayText;

... im Empfangs-Event ...

Invoke( DisplayHandler );

[EXDW]

M.A. Jackson schrieb:

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.

=> "Wenn denn entgegen allen Warnungen und Bedenken gerade eine Performanceoptimierung unumgänglich ist, dann sollte sie immer nur aufgrund einer detaillierten Analyse mit einem Profiler begonnen werden. Denn nur wer mit einem Profiler nachvollziehbar Performanceengpässe lokalisiert hat, kann während und nach der Optimierung prüfen, ob und inwiefern er sie geweitet hat."

[loks]

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.

In dem konkreten Fall wird es wahrscheinlich klappen, ich wollte mit meinem Post darauf hinweisen das das anlegen der neuen Objekte durchaus ein im .NET-Framework bewußt eingesetzter Mechanismus zur Vermeidung von race-conditions ist. Bestes Beispiel ist die String-Klasse wo ja jede Operation auf einem String immer ein neues Objekt erzeugt anstatt das bestehende zu manipulieren. Auch hier war das Hauptargument für diese Vorgehensweise Thread-Safeity ohne die notwendigkeit eines Locking.

Es ist ja auch nciht ungewöhnlich das man dann später denkt: Hey, daß hat ja wunderbar funktioniert, dann mach ich das doch immer so...

[hustbaer]

-com- schrieb:

Ich habe diesen Beispielcode im Netz gefunden:

private void serialPort1_DataReceived(object sender, System.IO.Ports.SerialDataReceivedEventArgs e)
{
    ...
    this.Invoke(new EventHandler(DisplayText));
}

Mir missfällt dieses new, bei jedem Aufruf wird ein neuer EventHandler erzeugt.
Das kann man doch effizienter lösen?

Äh.
Membervariable?

[EXDW]

Erst Messung, sofern die Performace dort leidet kann es angepasst werden.
Nichts ist unnützer als Ungemessene Pseudo-Optimierungen. Kann eher Probleme geben, zb die bereits angesprochene Thread Sicherheit.

[hustbaer]

CSL schrieb:

Erst Messung, sofern die Performace dort leidet kann es angepasst werden.

Jau

loks schrieb:

Wenn Du agegen ein zentrales Objekt verwendest mußt Du eventuell auch locking benutzen um race-conditions zu vermeiden...

&

CSL schrieb:

Kann eher Probleme geben, zb die bereits angesprochene Thread Sicherheit.

Also wenn ich genau den hier skizzierten Fall "auf Membervariable" übersetze, und zwar auf die einfachste mir bekannte Art, dann kann ich mir nicht vorstellen wie da Thread-mässig irgendwas schief gehen sollte/könnte/würde.

Also
* delegate im ctor anlegen und in (readonly) Membervariable merken
* in Funktion dann einfach Invoke(m_myLalaDelegate) und gut is

Hab ich was übersehen?

[EXDW]

Ja hast du, du weißt nicht ob es tatsächlich Probleme gibt oder nicht, und wieso ein Risiko eingehen wenn das Ergebnis fragwürdig ist?
=> Warum ändern (und ein RIsiko eingehen) wenn es so wie es gezeigt wird auf jeden Fall funktioniert?

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.
Gerade in C# ist ein häufiges new doch völlig normal, ich denke da an INotifyPropertyChanged, das Property des events, das wird mal locker mehrere Tausend mal pro Sekunde erstellt, und da hat man weiterhin keine Einbuße.

[hustbaer]

CSL schrieb:

Ja hast du,

aha. was?

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".

=> 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.

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.

[-com-]

hustbaer schrieb:

Äh.
Membervariable?

Äh. Jepp!

-com- schrieb:

...vergleiche es mit der Möglichkeit nur ein Objekt zu haben, nämlich dieses new EventHandler(DisplayText) als Membervariable

[EXDW]

hustbaer schrieb:

CSL schrieb:

Ja hast du,

aha. was?

Keine "optimierung" wo es nicht nötig ist, da man so Fehler produzieren 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.

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.

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.

[/quote]
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).

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.

[a]

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.

[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?

[-com-]

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