> On Jul 21, 2016, at 6:18 PM, Richard Bair <richard.b...@oracle.com> wrote: > > Hi Steve, > > It could be a benchmark problem, although I wouldn’t be surprised at all if > the benchmark was exercising the platform in some way that was CPU limited. > Assuming it is CPU limited (and not going multi-core), I think the problem > really comes down to what Markus said: > >> The limiting factor is the single-thread architecture of rather all parts of >> JavaFX. The only real difference you see between machines is not correlating >> with neither number of CPU cores nor GPU cores, but only with CPU frequency, >> roughly spoken. Short term fixes will only provide little improvement, by >> optimizing the critical execution path (i. e. produce hot spot histogram >> using a profiler), for example improvement clipping, caching, etc. Huge >> performance optimizations need an architectural change within JavaFX's >> "scenegraph-to-bitmapframe" (a.k.a. rendering) pipeline to use parallel >> execution in lots of places. Typical design patterns would be parallel >> iterations, work-stealing executors, fibers (a.k.a cooperative >> multi-threading, a.k.a CompletableFuture), and last but not least >> partitioned rendering (a.k.a tiled rendering). >> >> I am pretty sure you can add a lot more ideas to the list and produce great >> performance, scaling linearly with number of CPU cores / GPU cores, but this >> somes at a cost: Risk to introduce hard to track bugs, and needed manpower. >> >> If somebody has at least a lot of free spare time, I am pretty sure Kevin >> could easily provide a huge set of work items in this area. :-) > > > JavaFX was setup to be multi-threaded — in fact there are always at least 2 > threads — the application / scene graph thread and the render thread. Going > way, way back the goal was for multi-core computation/rasterizing on the NG > side (Prism), but it didn’t get done for a variety of reasons. I couldn’t > even say what kind of performance win/loss it would bring. I’m sure for some > workloads it would be way better,but for many others it probably wouldn’t > make any difference. A lot of other more pressing features had to be > implemented first which would allow people to build apps at all on top of FX > (like controls and effects and animations and so forth), and Prism has served > us really well. > > There are a few places we could play with fork/join to see if we can get > performance boosts, all of which would be tricky and have to be done very > carefully because they are part of highly tuned code paths: > Computing and applying CSS styles > Computing bounds > Computing layout
^ That. Computing layout and CSS is the most time consuming aspect of my application. I get pauses of more than a second or two in some cases for only a few thousand nodes. Recently JDK-8153329 was fixed which helped a little (e.g. 3-4 seconds to add a panel full of controls to my UI down to 2-3 seconds)… but it lead me to believe that these highly tuned code paths could use more tuning. Adding or remove nodes can be very expensive. I suspect changes in bounds can be very expensive. And it seems that Path drawing is expensive. That’s what would help my application the most. Cheers, Scott
