[teamfx] Re: "Performance einzelner Controls" - aus Danny Althoff: Re: Trotzdem weitermachen ;-) ?

  • From: Benjamin Gudehus <hastebrot@xxxxxxxxx>
  • To: teamfx@xxxxxxxxxxxxx
  • Date: Mon, 21 Dec 2015 14:31:19 +0100

Da passiert ja schon mehr in einem JavaFX TextField als in einem Swing
TextField, oder?

Übernimmt das bei Swing nicht teilweise auch das Betriebssystem? Naja, der
Layout- und CSS-Pass ist bei JavaFX so ausschlaggebend. Da kann man
bestimmt noch etwas optimieren. Einer vom Google Chrome Team hat mir das
auch bestätigt, dass Relayouts sehr kostspielig sind. Der Vorteil bei
Chrome sind aber sicherlich die eingebauten Entwicklerwerkzeuge für
Performancemessung und -visualisierung. Ich hatte da mal ein wenig versucht
Logger einzubauen, um dann die Messungen wahlweise in Textdateien,
System.out oder über einen Socket auszugeben.

Apropos Renderer-Optimierung: Auf der JavaOne 2013 gab es von Oleg Mazurov
den Vortrag “Optimizing JavaFX Applications”. Eigentlich absolut essentiell
zum Verständnis von JavaFX Application und Renderer Thread, jedoch leider
im Netz bisher schwer zugänglich gewesen. Der Vortrag ist mittlerweile
endlich auch auf YouTube angekommen (
https://www.youtube.com/watch?v=dw8se4uA1qc); PDF-Folien sollten auch gut
auffindbar sein; Parleys (wo der Vortrag ursprünglich abrufbar war) ist ein
bisschen komisch mit der Rausgabe von Videos und PDFs.

[image: Inline image 1]


2015-12-21 13:59 GMT+01:00 Dirk @ Google <dlemmermann@xxxxxxxxx>:

Auch wahr.

Vielleicht ist es schlicht und einfach die Komplexität von JavaFX
Controls. Da passiert ja schon mehr in einem JavaFX TextField als in einem
Swing TextField, oder? Zum einen durch die Verwendung von CSS, zum anderen
durch das ganze Property Binding. Selbst wenn man CSS noch schneller machen
könnte, wäre so ein JavaFX Textfield sicherlich fetter als ein Swing
Textfield und ein Vergleich der selbigen miteinander nicht unbedingt fair.
Swing war für Rechenleistung von 1996 entwickelt worden, JavaFX für heutige
Maschinen.

Just thinking out loud ….

Dirk


Am 21.12.2015 um 13:54 schrieb Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx
:

Genau das war auch mein test damals um zu zeigen, dass es nicht der SG
ist sondern Layout-Pass & CSS wobei der Layout-Pass bei Shapes auch sehr
einfach ist ;-)

Tom

On 21.12.15 13:52, Dirk @ Google wrote:
Bei mir war das ähnlich. Wollte damals für FlexGanttFX alle Balken als
Nodes realisieren. Die Zeit ging hauptsächlich bei der Anwendung von CSS
verloren. Am Scenegraph liegt es wohl weniger. Wenn man bei diesem Test
einen „einfachen“ Node wie Rectangle verwendet (also keine Skins, wenig
CSS), dann ist alles blitzschnell da.

Dirk

Am 21.12.2015 um 13:49 schrieb Tom Schindl <
tom.schindl@xxxxxxxxxxxxxxx>:

Hallo,

Ich hatte einen ähnlichen Fall einmal mit the PulsLogger betrachtet und
die Zeit ging zu ca 70% im CSS verloren und zu 30% im layout pass.

Tom


On 21.12.15 13:47, Dirk @ Google wrote:
Ja danke, ich hab’s inzwischen. Bin schon am profilen.

Am 21.12.2015 um 13:46 schrieb Markus KARG <markus@xxxxxxxxxxxxxxx
<mailto:markus@xxxxxxxxxxxxxxx>>:

War als Anhang an Björn's Mail dran.
-Markus

*From:* teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>
[mailto:teamfx-bounce@xxxxxxxxxxxxx] *On Behalf Of *Dirk @ Google
*Sent:* Montag, 21. Dezember 2015 10:52
*To:* teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
*Subject:* [teamfx] Re: "Performance einzelner Controls" - aus Danny
Althoff: Re: Trotzdem weitermachen ;-) ?

Code? Möchte es gerne auf meinem Mac ausprobieren.

Dirk


Am 21.12.2015 um 09:13 schrieb Björn Müller
<bjoern.mueller@xxxxxxxxxxxxxxx <mailto:
bjoern.mueller@xxxxxxxxxxxxxxx>>:


...also ich mach' das hyper-pragmatisch: große Anzahl von Controls
erzeugen und Zeitmessung durch expliziten Button, wenn die Controls
sichtbar sind. ;-)
Mini Programm im Anhang. In der Console werden dann entsprechende
Zeiten ausgegeben.

<cegageib.png>
Bei mir (Pentium i7, 3.1GHz) dauert der Erstaufbau von 3000 Controls
knapp 3000ms. Nach clearen, kostet dann der Zweitaubau 1.300ms.

Viele Grüße! Björn

Am 21.12.2015 um 08:51 schrieb Benjamin Gudehus:
Am Rande eine kleine Frage:
Genaue Messungen und Szenarien kann ich gerne nachreichen, erstmal
will ich mal schauen, wie bei Euch die Stimmungslage hier ist.
Wie messt ihr die Zeitspanne für den Aufbau der Nodes? Soweit ich
weiß kam man das auch nur per scene und es muss auf private fields
zugegriffen werden.
-Benjamin
On Dec 18, 2015 10:17 PM, "Casall, Alexander"
<alexander.casall@xxxxxxxxx <mailto:alexander.casall@xxxxxxxxx>>
wrote:
Hey Björn,

Hast du neue Erkenntnisse bzw. eine Bug-ID?

VG
Alex

*Von: *<teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx>> im Auftrag von Björn
Müller
<bjoern.mueller@xxxxxxxxxxxxxxx <mailto:
bjoern.mueller@xxxxxxxxxxxxxxx>>
*Antworten an: *"teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx
"
<teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
*Datum: *Mittwoch, 25. November 2015 19:08
*An: *"teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>"
<teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>>
*Betreff: *[teamfx] Re: "Performance einzelner Controls" - aus
Danny
Althoff: Re: Trotzdem weitermachen ;-) ?

...ja, und zwar hier konkret das Erzeugen des Skins zur Instanz.
Bin
gerade am Zusammenkehren meiner PerformanceTests + Messungen und
mache daraus bzgl. des TextFields mal eine ordentliche JIRA-Meldung
draus. Wird aber erst morgen gegen späteren Nachmittag/Abend sein,
da unterwegs...

Mehr Threads beim Erzeugen der Instanzen? Müssen die nicht im
FX-Thread erzeugt werden?
Sei's drum: Textfelder sind aus meiner Sicht immer noch
ziemlich-lightweight Controls. ;-)


Freundliche Grüße! Björn


------------------------------------------------------------------------
Björn Müller
+49 (0) 6223 484147, bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
CaptainCasa GmbH, Hindemithweg 13, D-69245
Bammental, http://www.CaptainCasa.com <http://www.captaincasa.com/


------------------------------------------------------------------------

Am 25.11.2015 um 18:57 schrieb Markus KARG:
Damit ich es richtig verstehe: Ist das *Erzeugen* der Instanzen
ein
Problem (lässt sich ja mit mehr Threads kompensieren) oder die
Nutzung zur Laufzeit?
-Markus


*From:*teamfx-bounce@xxxxxxxxxxxxx
<mailto:teamfx-bounce@xxxxxxxxxxxxx> [mailto:
teamfx-bounce@xxxxxxxxxxxxx] *On
Behalf Of *Björn Müller
*Sent:* Mittwoch, 25. November 2015 09:34
*To:* teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
*Subject:* [teamfx] "Performance einzelner Controls" - aus Danny
Althoff: Re: Trotzdem weitermachen ;-) ?


Hi zusammen,

@ "es GIBT Probleme mit der Performance einzelner Elemente" aus
untiger Meldung:

Ganz konkret ist aus meiner Sicht das *TextField*miserabel (bzw.
alles, was unter TextInputControl liegt). Wir haben Szenarien, in
denen durchaus mal 600 (und mehr) Textfelder aufgebaut werden.
Unter Swing war das problemlos, unter FX eine Sache von deutlich
mehreren 100ms. Es geht mir um die Performance beim Aufbauen des
Dialogs - es geht nicht um die Bedienperformance, wenn die Felder
mal stehen.

*Ist dieses Problem auch bei Euch relevant?
Gibt es da irgendwelche Aktivitäten im FX Bereich?
*
Genaue Messungen und Szenarien kann ich gerne nachreichen, erstmal
will ich mal schauen, wie bei Euch die Stimmungslage hier ist.

Wir sind mittlerweile dazu übergegangen, in solchen
"Massen"-Szenarien das TextField-Control nur dann zu rendern, wenn
es den Focus bekommt - und sonst ein sparsames Text-Control zu
verwenden. Dies ist aus meiner Sicht aber keine optimale Lösung -
ich wehre mich etwas dagegen, ein TextField als teure Resource zu
betrachten!

Wenn aus Eurem Feedback eine gemeinsame Relevanz ablesbar ist,
dann
wäre das aus meiner Sicht ein konkreter inhaltlicher Punkt, sich
dort gemeinsam abzustimmen. - Und wenn's keine gemeinsame Relevanz
gibt, dann betreiben wir hier eben weiter unser
Focus-Text-TextField-Switchen... ;-)

Freundliche Grüße! Björn

PS: da dieses meine erste Wortmeldung ist, will ich nicht
versäumen
zu erwähnen: Markus - Danke für Aufbau und Organisation der ersten
Schritte!


------------------------------------------------------------------------
Björn Müller
+49 (0) 6223 484147, bjoern.mueller@xxxxxxxxxxxxxxx
<mailto:bjoern.mueller@xxxxxxxxxxxxxxx>
CaptainCasa GmbH, Hindemithweg 13, D-69245
Bammental, http://www.CaptainCasa.com <
http://www.captaincasa.com/>

------------------------------------------------------------------------

Am 25.11.2015 um 09:05 schrieb Danny Althoff:

Hi Jens, hi Markus, hallo Mailingliste,

vielen Dank für das Teilen des Artikels. Es ist hilfreich die
Meinung von anderen zu diesem Thema einzuholen, damit alle
Sichtweisen ihr Gehör bekommen.

Wieso der Artikel IMHO nicht gut ist:
- es werden falsche Metriken verglichen, der bloße Vergleich der
"Trends" von Google ist wenig aussagekräftig, da nicht
eingeflossen ist, ob es sich hier um Probleme handelt, oder aber
um technische Dokumentation (was nicht gut dokumentiert ist,
erzeugt ebenfalls solche Suchhits)
- wenn JavaFX eben nicht die alten fehlerhaften Konzepte
verfolgen sollte (by Design), dann ist es auch verständlich, dass
hier nicht sofort jeder aufspringt, weil es eben NICHT so schnell
mit alten Swing/AWT-Kern gedanklich matched
- es fehlt eine komplette Betrachtung der JavaScript-Welt,
gerade mit AngularJS und JQuery sowie dem Wandel mit HTML5 sind
viele Dinge von Applets und Flash weggewandert, somit gilt auch
hier ein weiterer "Personenkreis" als abgeworben/verloren (ich bin
selber jemand, der in beiden Welten unterwegs ist, als JS und Java
:P nicht Flash/Applets)

Was aber auch wahr ist im Artikel:
- es fehlt an einer klaren Werbestrategie und einer klaren
Roadmap, durch meine Arbeit am JavaFX-Maven-Plugin stolper ich
umso häufiger auf halb-fertige Ansätze, Änderungen welche nicht
sofort ersichtlich sind, sowie einer ungewohnt verstreuten Architektur
- es GIBT Probleme mit der Performance einzelner Elemente, da
diese unterschiedlich nativ gebaut/angepasst sind
- der ganze Artikel gehört zur Kategorie "RANT", und genau als
solches sollte man diesen auch ansehen
- Flash und Applets sind tot und gehören eingemottet
- weiterhin muss Java unter seindem "Experiment" der
Java-Applets leiden, ist einfach zu traumatisch gewesen


Was mich persönlich stört ist die fehlende Richtung (z.B. alles
was AWT/Swing kann, plus noch viel mehr und "schöner"?!) und den
Release unfertiger Teile. Die Aufsplittung in "JavaFX ist
opensource" hingegen erachte ich für eine falsche
Herangehensweise, denn OpenSource heißt für mich nicht nur die
Offenlegung des Quelltextes sondern auch die Akzeptanz einer
Teilnahme der Community. Klar, wir bauen die Werkzeuge dafür, oder
promoten diese Technik, aber sie ist als Ganzes vom OracleJDK zu
sehen. JavaFX ist nun im Kern von Java enthalten, daher ist die
Betrachtungsweise eines Zusatzes falsch. Mag historisch begründet
sein, war ja auch wirklich ein zusätzlich installierbares Paket
(und ist es bei OpenJDK + OpenJFX weiterhin so), aber alle JDKs
sind nicht mehr so.

Was mich aber freut ist überhaupt die Möglichkeit "von Hause aus"
native Launcher erstellen zu können oder aber ganze Bundles zu
bauen, das ist sogar der Grund, wieso ich mir nach dem Reinfall
mit JavaFX 1.x/2 zurück zu JavaFX 8 gekommen bin. Die
Möglichkeiten sind erstaunlich, wenn auch etwas wenig beworben.

Fazit: es gibt kritische Stimmen, aber das ist gut, es hilft
besser zu werden ;) also lasst es uns besser machen!


Schönen Gruß an den Rest
Danny


Am 24.11.2015 um 23:04 schrieb Markus KARG:

Jens,



ich halte den Artikel für eine sehr einseitige und grundlos
pessimistische Betrachtung. Der Bedarf für JavaFX ist da, und
Oracle bezahlt faktisch eine ganze Menge an Menschen, die daran
arbeiten. Nur sieht Oracle keinen kommerziellen Nutzen und
begrenzt daher die Menge an Mitarbeitern auf "weniger als uns lieb
ist". Aber ist es denn Oracle's *alleinige* Aufgabe JavaFX zu
entwickeln? Ich meine, es ist ja Open Source... Oracle ist an der
Hilfe durch TeamFX sehr interessiert, und meine persönliche
Erfahrung ist, dass JavaFX auch stark nachgefragt wird -- aber
eben nur dort, wo ein Fat Client gewünscht ist, nicht dort, wo man
"nur" einen Rich Client benötigt -- das sind nunmal aber zwei
verschiedenen Paar Stiefel. Was also will der Autor erreichen? Das
ist mir ehrlich gesagt unklar!



Ich werde demnächst nochmals ein Gespräch mit Kevin haben zur
Klärung, wie es weitergeht. Bis dahin hake ich den in sich
inkonsistenten und nicht wirklich wahrheitsgemäßen Artikel einfach ab.



-Markus





*From:*teamfx-bounce@xxxxxxxxxxxxx
<mailto:*teamfx-bounce@xxxxxxxxxxxxx> [mailto:
teamfx-bounce@xxxxxxxxxxxxx]
*On Behalf Of *Jens Deters
*Sent:* Sonntag, 22. November 2015 18:16
*To:* teamfx@xxxxxxxxxxxxx <mailto:teamfx@xxxxxxxxxxxxx>
*Subject:* [teamfx] Trotzdem weitermachen ;-) ?




Should Oracle Spring Clean JavaFX?


Why JavaFX hasn't taken off, and what Oracle can do to
improve it's place in the ecosystem.

“Todays students sometimes learn JavaFX or Swing in class and
often find out that they learned yesterdays technologies as they
leave the classroom!“



"I think that the most important thing to do here is to move
students off of JavaFX and into more sustainable areas in Java
such as the newer server/HTML frameworks or to mobile, this will
still provide some of the pleasurable "tingle" of seeing your UI
run but would provide a more sustainable skill set."





https://dzone.com/articles/should-oracle-spring-clean-javafx





— Jens










--



Björn Müller
CaptainCasa GmbH, Hindemithweg 13, D-69245 Bammental
+49 (0) 6223 / 484147
bjoern.mueller@xxxxxxxxxxxxxxx <mailto:
bjoern.mueller@xxxxxxxxxxxxxxx>
<Test_91_Performance.java>


--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck





--
Thomas Schindl, CTO
BestSolution.at EDV Systemhaus GmbH
Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck
http://www.bestsolution.at/
Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck




JPEG image

Other related posts:

  1. Home
  2. teamfx
  3. Archive
  4. 12-2015