commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [Math] Issues 650, 675, 676
Date Sun, 09 Oct 2011 21:44:52 GMT
> >>>>> Referring to:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> In the absence of additional comments I'm proposing to resolve those
> >>>>> 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.
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).

> 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"!

In conclusion, with the current code in trunk, the difference between the
"literal arrays" and "resources" alternatives is less than ~0.5 millisecond.


[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:
For additional commands, e-mail:

View raw message