From: Rick M. <obj...@gm...> - 2017-03-28 19:24:19
|
On Tue, Mar 28, 2017 at 3:16 PM, Erich Steinböck <eri...@gm... > wrote: > I've always wondered, why calling RxCalcSqrt() is so slow that it's faster > to implement Newton's method in your own Rexx code. > > I tracked this down: it has nothing to do with the RxMath library, but > it's pervasive for all code run from a native library. > > On a specific machine, calling SysDropFuncs(), which is a no-op in > rexxutil, takes some 75 microseconds, which is surprisingly slow. (This is > on Windows, on Linux this is more in the 20+ usecs) > > If run like below, a call will only take 1 microsecond > > ~~~~ > call dropfuncs > ::routine dropfuncs external 'library rexxutil SysDropFuncs' > ~~~~ > > The delta seems to come from the fact, that external routines' search > order runs functions from a library package *after* checking macrospace > pre-order, but external ::routine functions *before* macrospace pre-order. > > So, while those who require maximum performance can always define > `::routine external` instead of directly calling native library functions, > most users will probably not know about this. > > Any ideas how we could/should improve this for the normal users? > > Eliminate the macrospace and the global registration table managed by rxapi (only half joking here). The bit cause of the overhead is the IPC call to the rxapi server to check if anything is available. I've been pondering this issue for years without any good solutions that maintain compatibility. It would be nice to cache the resolution results locally, but the resolved target can actually change from call-to-call. Rick Rick > ------------------------------------------------------------ > ------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Oorexx-devel mailing list > Oor...@li... > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > |