JADE Environment Development Ideas

John Beaufoy 15/06/2018 1:30:31 PM
I've certainly had instances where I opted for a bloated method over smaller more readable components to squeeze out performance.
That said I'm not convinced the answer is explicit in-lining, rather a preference for any optimisations like this to occur under the hood based on variables such as what that "inner" function does, cache sizes, processor architecture etc.

Kevin Saul 15/06/2018 7:53:53 AM
Optimizations of this nature would likely be of most benefit to string related functions, as I suspect it'd reduce the number of times strings need to be copied as part of a method call.

James Burnby 13/06/2018 1:11:19 PM
Please note that this is raised as an idea and not to fix any current issues and of course there are other performance tweaks on a case by case basis. When the overhead is milliseconds but you multiply it by billions/trillions it becomes a problem. I am pretty sure languages such as C++ didn't introduce inline expansion, just because. A previous non Jade project involved 240 trillion iterations, fortunately I could break it out in to individual methods.

Ty Baen-Price 13/06/2018 10:24:36 AM
Guys, method calls aren't the performance problems you're looking for. I just did a rudimentary test (on my desktop), and I'm getting sub-microsecond times for method calls. I am unable to upload my schema to JEDI, but if you want to take this to the forums we can talk about it in more detail. Just quickly though, we have seen that thrashing the method cache can look like what you're describing, so look there first.

Software Medical Infomatics Limited 12/06/2018 6:56:52 PM
I wonder if it's possible for Jade to reduce the overhead of calling methods. This does seem to be a known issue that method calls are relatively expensive in Jade and any process that makes a lot of method calls can often be significantly optimised by inlining code. The inline expansion idea is good, but ultimately solving the problem at the wrong level, I think.