Just submitted PR with example implementation: https://github.com/apache/cordova-android/pull/440
On 2018/05/01 16:42:11, chemeri...@gmail.com <chemeri...@gmail.com> wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org For additional commands, e-mail: dev-h...@cordova.apache.org
