Le 09/10/2011 13:56, sebb a écrit :
On 30 September 2011 23:03, 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.
It's not clear if that alone is sufficient to deal with the OP's use case.
I think both way are fine for this use case. I met Alexis last week and
he was happy with the improvements.
Luc
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: 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
