On 9 October 2011 22:44, Gilles Sadowski <gil...@harfang.homelinux.org> wrote: >> >>>>> Referring to: >> >>>>> https://issues.apache.org/jira/browse/MATH-650 >> >>>>> https://issues.apache.org/jira/browse/MATH-675 >> >>>>> https://issues.apache.org/jira/browse/MATH-676 >> >>>>> >> >>>>> In the absence of additional comments I'm proposing to resolve those >> >>>>> issues. >> >>>>> Please let me know whether there are pending objections to my suggested >> >>>>> solutions. >> >>>> Regarding MATH-650 (FastMath) >> >>>> >> >>>> If the proposal is to use resources instead of static arrays, then I >> >>>> disagree, because resources are significantly slower than static >> >>>> arrays. >> >>>> >> >>>> I am opposed to storing the arrays in package protected classes, >> >>>> because that exposes the data unnecessarily. >> >>>> >> >>>> However, if you really cannot agree to the including the static arrays >> >>>> within the FastMath class itself, then I suggest using separate >> >>>> classes with private arrays and package-protected getters. >> >>> It has been shown that literal arrays are faster than resources in one >> >>> micro-benchmark instance: Namely, an application that consists of a >> >>> single >> >>> function call. We still wait for a real use-case where the difference >> >>> will >> >>> significantly matter. >> >> The original reason the JIRA was raised is probably solved by moving >> >> to on demand init. >> > I've been saying that same thing more than a few times, in various ways. >> > >> >> It's not clear if that alone is sufficient to deal with the OP's use case. >> > At one point, Alexis wrote (on JIRA): >> > "A response time with the magnitude of 100ms is really perfect !" >> > >> > Then I provided a test case, following Luc's indication of the typical >> > functions called in the original use case. >> > On my machine, the timing for all alternatives was below 100 ms. >> >> 100ms on a fast machine doing nothing else is not awe-inspiring. > > I don't understand whether you agree with my position i.e. that all > alternatives having times below 100 ms can be considered sufficiently good.
AIUI, the 100 ms was for loading time on the Android system, not a desktop or laptop. > I recall that the sole worry clearly expressed by the original poster was > the psychological effect of waiting "too long" for the result. [For an > interactive application, waiting ~100 ms is not noticeable; it's far less > than the time we routinely wait between a click on an icon, and the opening > of the application window.] > >> Holding a static class lock for that long is in fact at *bad >> thing*. > > I don't understand. What do you mean? Which class, which lock? Can you > illustrate the items using the current issue? > >> People way smarter than me have come up with great ways to >> work around delays in app startup times. I prefer not to have to >> use those things, and, more importantly, not to force others using >> my code to use them. > > The point is that there are no delays anymore (solved by IOD). No, IOD only solves the delays for method calls that don't use the arrays. >> I favor the static arrays solution, IIUC what the timing tests have >> shown. Specifically, if static arrays can reduce class loading time >> by more than 50ms, I think we should use them. If there is some >> other workaround that allows the resource loading and does not >> increase loading time more than 50-100ms, I am OK with the resources >> approach as well. > > [I guess that we are using the timings on my machine as a baseline.] > There is no reduction of more than 50 ms by using literal arrays: at most 12 > ms, with "FastMath" bloated with the literal arrays. > > A strange thing is that moving the arrays to their own class increased their > loading time by ~6ms, while decreasing the resource loading time by about > the same amount.[1] I mean that it is as if, somehow, the literal arrays[2] > were incurring a penalty to other functionalities (the resource loading in > this case) called from within "FastMath"! I don't think you can conclude that without further evidence. > In conclusion, with the current code in trunk, the difference between the > "literal arrays" and "resources" alternatives is less than ~0.5 millisecond. On your system. On an Android phone it will be a considerably bigger difference > > Gilles > > [1] I also gained some 1-2 ms using "nio" and reducing the number of I/O > method calls. > [2] Even when they were not used, e.g. when "LOAD_RESOURCES" was set to > "true" in order to use the resource loading alternative. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
