I've created performance test for different @CordovaMethod implementations that allows to measure timings - https://gist.github.com/chemerisuk/287e6cd6e1aa61a5680027967008b702. On my machine results are like below:
OldCordovaPlugin: 0.03s with v=6000000 MethodCordovaPlugin: 0.14s with v=6000000 MethodHandleCordovaPlugin: 0.12s with v=6000000 LambdaCordovaPlugin: 0.09s with v=6000000 Cache disabled MethodCordovaPlugin: 0.70s with v=6060000 MethodHandleCordovaPlugin: 0.87s with v=6060000 LambdaCordovaPlugin: 6.37s with v=6060000 So as you can see various strategies have different performance. LambdaCordovaPlugin which uses Java 8's lambdas has the best invokation performance, but also it has the slowest initialization time. In result I'd vote for MethodHandleCordovaPlugin implementation. It's the most balanced one. Keep in mind thought it looks 4x slower, to calculate extra time you should divide the time on number of invokations: (0.12s - 0.03s) / (1000000 * 3) = 27 ns. Feel free to make your comment. On 2018/05/01 08:49:12, Frederico Galvão <frederico.gal...@pontoget.com.br> wrote: > Although a relative performance metric is important and a good starting > point, it's by far the most overused checkpoint to stop something from > being considered in programming, when in reality absolute numbers and > context are the truth. It doesn't matter if, from a arbitrary 200ms from > activity lifecycle start to deviceReady we increase it to 220ms to process > annotations, and then have an extra 5ms on each call compared to 1ms from > the pure call cost in a pool of 100ms per "request" (from js callsite to > callback). That's a relative 5x increase in time taken per call, indeed, > but a useless drop in the ocean near what's the total time of communication. > > Readability and maintainability are very important aspects of a > framework/protocol when the plugin author is an end user too. As a mere > cordova user, I'd rather see this taken to a deeper level of consideration > and benchmarking before discarding. > > 2018-05-01 0:22 GMT-03:00 Simon MacDonald <simon.macdon...@gmail.com>: > > > > > > > On Mon, Apr 30, 2018 at 12:37 PM Wojciech Trocki <wtro...@gmail.com> > > > wrote: > > > > > > Maybe I'm not understanding the goal here and it would be clearer with an > > > example, but it looks like this would split each action out into its own > > > class? I'm not sure what advantage there is to that, since you'd lose > > > access to all the CordovaPlugin members like the webview and > > > CordovaInterface. > > > > > > > I agree with Darryl here, I'm not sure what that PR actually makes better? > > It seems to make the problem worse. > > > > > > > From a plugin author standpoint, a @CordovaMethod annotation to expose > > > specific plugin methods to JS would be ideal, but it's not such a > > > convenience that it's worth any performance hit. The string-based execute > > > is clunky, but not all that much of a problem if you just use it to > > > dispatch to other methods. > > > > > > > If annotations are 5-6 times slower than normal method calls I think this > > was a good idea that the OS can't handle. We are dealing with devices where > > 100ms makes the difference between a "smoothly performing" app and a > > "janky" app. > > > > Simon > > > > > > -- > > *Frederico Galvão* > > Diretor de Tecnologia > > PontoGet Inovação Web > > > ( +55(62) 8131-5720 > > * www.pontoget.com.br <http://www.pontoget.com/> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
