Häufige Erzeugung eines EventHandler Objekts vermeiden.

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.

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.

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

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

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

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

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.

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.

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?

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.