You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Indeed it seems a bit dated. Improving kscript overhead is still important. So providing some drip/nailgun/... option, would be nice.
Not sure what the actual performance gain of drip would be. I've tried a quick hack, but since we use kotlin and not just java, it's not a simple java->drip replacement.
For now the best path towards better perfomance is imo pr #102 which is at the top of my most-wanted kscript impros. See benchmarking results under #93.
Once it has been merged, we're down to a single call to kotlin (from currently 3), and we could think about drip again.
@holgerbrandl Thanks! I don't understand why we need kotlin in the case of cached scripts? Isn't the cached script just a jar we can run with a single java command? Perhaps we can put the cached jar in the same directory as the script with the same name (just having an extra .jar), so the user can herself call drip on the cached jar?
For running the jar, java would be sufficient. But changing it now, would break backwards compatibility since users may have specfied runtime options with //KOTLIN_OPTS.
drip still seems like an interesting objects, once pr 102 has been merged. Then we just have to deal with one external tool invocation instead of 3 (as of now).
Activity
ilanpillemer commentedon Mar 26, 2018
holgerbrandl commentedon Mar 26, 2018
Indeed it seems a bit dated. Improving kscript overhead is still important. So providing some drip/nailgun/... option, would be nice.
Not sure what the actual performance gain of drip would be. I've tried a quick hack, but since we use
kotlinand not justjava, it's not a simple java->drip replacement.For now the best path towards better perfomance is imo pr #102 which is at the top of my most-wanted kscript impros. See benchmarking results under #93.
Once it has been merged, we're down to a single call to
kotlin(from currently 3), and we could think aboutdripagain.NightMachinery commentedon Mar 26, 2018
@holgerbrandl Thanks! I don't understand why we need
kotlinin the case of cached scripts? Isn't the cached script just a jar we can run with a single java command? Perhaps we can put the cached jar in the same directory as the script with the same name (just having an extra.jar), so the user can herself call drip on the cached jar?holgerbrandl commentedon Mar 26, 2018
For running the jar, java would be sufficient. But changing it now, would break backwards compatibility since users may have specfied runtime options with
//KOTLIN_OPTS.drip still seems like an interesting objects, once pr 102 has been merged. Then we just have to deal with one external tool invocation instead of 3 (as of now).
holgerbrandl commentedon Aug 17, 2018
Closed due to inactivity. Feel welcome to reopen if needed.