Excessive memory usage is more of a well documented JDK problem that impacts 
the performance of many applications. Especially when having a large collection 
of instances of the same class. In C++ an array of objects are in memory 
similar to an array of structs. In Java they are arrays of pointers to objects 
on the heap.

This could of course be worked around by storing data in arrays and using 
classes to wrap those arrays. In one project I stored X and Y coordinates in an 
array. I had a class with getter and setters but also with a reference to the 
array and index. On top of that I had what worked similarly to a standard 
object pool but in fact only had a few instances of the object, changing index 
of a free object rather than allocating a new. For simplicity I used an array 
for X and another for Y.

This pattern can be refined to align data in various ways for better cache 
performance. And in our case there may be alignments that gives better GPU 
performance. After all it's usually the GPU that process our data. 

Of course it would be best if the JVM had better memory management including 
something similar to a struct array without pointers to objects. But there 
would still be need to have refinements. For example is it better to have 
XXXYYY, XYXYXY, or perhaps YXYXYX? That in turn depends on cache 
infrastructure, the order data is accessed and other factors. 

In order notes the main competition to JavaFX is other Java APIs such as Swing 
and it's Java2D. When it comes to performance we obviously have a clear winner. 
But JavaFX isn't shipped within major Linux distributions so it is yet 
considered experimental by many that use Swing. There are also competition from 
SWT used by Eclipse and Azureus/Vuze. Packaging is one problem but there are 
also UI components missing. The SWT on JavaFX implementation has a list of SWT 
components and their JavaFX counterpart. That list illustrates that there are a 
lot of work to do.

Of course once SWT on JavaFX is complete SWT will be eliminated as competition. 
Especially if Eclipse use JavaFX as its SWT backend. It would also mean that 
JavaFX is better equipped to compete with Swing as SWT already is a strong 
competitor to Swing.

However SWT has been held back due to stability problems which probably will 
not be in the way when it's based on JavaFX which is good enterprise code. 

As for competing with web technologies it would have helped if we had a modern 
browser plugin. JavaFX as an UI may not be faster than browser technologies. 
But Java bytecode is a lot faster than JavaScript. Take RPC for example. If you 
use browser technology you would probably be using Json at best. With Java you 
have binary protocols like Jboss Remoting which ia easy to code and much faster 
than using Json in JavaScript. 

Web technologies can only compete where there is an API implemented in 
something other than JavaScript. Once processing is done in JavaScript the it 
becomes a lot slower than Java. 

I would suggest creating a new fully sandboxed applet technology based on 
JavaFX instead of AWT/Swing. That of course would be incompatible with classic 
Applets but those are dead anyway. Make it at least as good as Flash perhaps 
with an IDE like the commercial flash IDE. I mean activescript vs Hotspot will 
not be a very fair match. 

Another competitor is Unity and similar game engines. As unity is based on mono 
and MonoDevelop we could do something similar using Java and eclipse. 

When it comes to web/client server Vaadin has been gaining a lot of ground. 
It's model of having a combined client and server code base using byte buddy or 
ASM to separate client and server into separate executables is impressive. I 
would like more control such as specifying @client or @server in order to 
control where execution take place. But more to the point I would like a JavaFX 
UI.

While web technologies are moving in on Java they do have a far way to go 
before they have what java has. We have Hotspot for starters and that's way 
ahead of JavaScript and Flash. What we don't have is browser integration.

Let's take the lessons learned from both Flash and Java Applets and make 
something awesome. That doesn't carry "java" in the name. Like OpenFX? Or 
"Arrow" (yeah I'm a nerd). This including the creative tools that Flash has but 
perhaps also with features that Unity has.



Kevin Rushforth <kevin.rushfo...@oracle.com> skrev: (10 april 2017 22:08:04 
CEST)
>We are planning some performance improvements in JDK 10, mostly in the 
>areas of CSS and layout. If you have specific concerns in other areas
>we 
>could look into them. Having a specific test case that shows a 
>performance problem would be a good start.
>
>-- Kevin
>
>
>Michael Paus wrote:
>> Hi,
>>
>> more and more people ask me why I am still doing GUI development in 
>> JavaFX instead
>> of following the  mainstream and use some web technology. One of the 
>> arguments
>> I could use in the past was performance but nowadays this does not 
>> seem to be such
>> a valid argument anymore. Web technologies are catching up quickly
>and 
>> JavaFX currently
>> has not much to offer here. Actually the general drawing performance 
>> is very bad compared
>> to what is in principle possible with a modern GPU. I even tried to 
>> use a TriangleMesh
>> to better exploit the graphics hardware but this approach is also 
>> limited by the fact that
>> a TrinangleMesh has an excessive memory usage (about 60 times its 
>> nominal memory
>> consumption). I would therefore like to ask whether there are already
>
>> any plans for Java 10
>> to improve this situation?
>>
>> Michael

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Reply via email to