davidholmes wrote:Hello David
Are you asking with respect to the different performance characteristics of one RTSJ API over another? Or in the sense of "my apps runs this fast on regular Java but slows down on an RTSJ implementation, how can I speed it back up?" ?
RTSJ API's define tools for solving real-time problems so if you need something you need it - you don't generally have a choice of doing it a few different ways and picking the "fastest". That said there are some areas where you can experience different latencies based on using, for example, real-time threads or async-event-handlers. But I suspect latencies are not what you are referring to.
Can you clarify what aspects of performance you are thinking about?
>That depends on the source of the latency. If it is inherent in the network stack then no, using the RTSJ will not help.
if I was running an application that got real time data with a latency of 7ms over a network, would I be able to significantly reduce this latency by using RTS?
Furthermore if I can reduce that latency by using RTS, is the reduction caused by simply using RTS or are there certain implementation principles that I should be following to reduce this latency?The aim is to remove/reduce all sources of latency that you can. This means using the right priority to ensure your data thread can run when it needs to. It means ensuring you don't execute unexpected code - doing class-loading and initialization, or JIT compilation - so you may need to use Initialization Time Compilation. It means ensuring you don't get preempted by GC, so either use NoHeapRealtimeThreads or else ensure (for Java RTS as opposed to the RTSJ) that the real-time GC is tuned properly. It means ensuring you don't get unexpectedly delayed waiting for resources - like locks, so don't unnecessarily synchronize between your data thread and other threads.
Also how do real time threads and async-event-handlers affect the latency in an application like the example I gave in the original post for example?Real-time threads and async-event handlers are your only means to utilize real-time priorities, so they help address that latency. Beyond that it depends on how your data processing is triggered. For example, if you need to read the data periodically then real-time threads can utilize waitForNextPeriod which is a timed blocking mechanism with low latency and greater accuracy that non-real-time timed-waiting. You can use an async-event-handler with a periodic timer, but, speaking for Java RTS, it will have longer latencies because timers are not as low-latency as using waitForNextPeriod (at least on Solaris ... not sure how they compare on Linux). Also unbound async-event-handlers have an additional latency due to the binding of a server thread to execute them.