For anybody who is interested in what options java has to invoke methods I recommend to read an interested link https://stackoverflow.com/questions/19557829/faster-alternatives-to-javas-reflection. Accepted answer has useful information and demo class where different technics tested. On my machine (macbook pro 13'' 2013) results like below:
$ java -version java version "1.8.0_25" Java(TM) SE Runtime Environment (build 1.8.0_25-b17) Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode) $ java TestMethodPerf direct: 0.02s, lambda: 0.02s, mh: 0.33s, reflection: 0.34s I do agree that performance should be strongly considerated before making any changes. Still thinking of the best way how to measure and analyze results for CordovaPlugin specifically. 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
