commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
Subject Re: [Math] Issues 650, 675, 676
Date Sun, 09 Oct 2011 11:56:30 GMT
On 30 September 2011 23:03, Gilles Sadowski
<> wrote:
>> >
>> > Referring to:
>> >
>> >
>> >
>> >
>> > 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.
It's not clear if that alone is sufficient to deal with the OP's use case.

> Independently, I think that the right way to load this kind of data is
> indeed via the "resources" functionality. If this is so, one should rather
> ask whether the loading time can be improved. In fact, I wonder why loading
> resources should be "so much" slower than arrays (18 ms vs 6 ms).

I wonder too. If you can make it go as fast as the preset arrays, then
I would be happy with that.

> Hence, if there is still no consensus on that issue,

I  think you are the only person who appears to be vetoing the local arrays.

I have yet to see a proper objection to leaving the arrays within the
FastMath class.
The code still generates the same results, and is proven faster in startup.
What is wrong with that?

> you are welcome to
> create the helper classes as you suggest (which, IIRC, is what I had also
> suggested from the outset).

This is slightly different from the original suggestion; IIRC that did
not include using getters.

> That way, both alternatives will be on an equal footing for further testing.

I don't follow that.

> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message