[
https://issues.apache.org/jira/browse/MATH-650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13159702#comment-13159702
]
Gilles commented on MATH-650:
-----------------------------
I regret that we could not agree about what delay can be deemed _short enough_.
Literal arrays (or loading from resources) reduce the delay but the big gain
was through IOD. _That part_ should have closed this specific issue, not the
additional pre-computation "feature".
IMHO, the literal arrays (or resources) trick is a temporary workaround, until
it is clear for all that the time gain has become insignificant (and the
"RECOMPUTE_TABLES_AT_RUNTIME" can be used again).
The "resources" solution may not be ideal, but neither is the literal arrays
one; we have divergent listings of what is more important.
As for the technical limitations which you point out, maybe that they can be
lifted, and if so it could even also improve the efficiency of that alternative.
I can never agree that using literal arrays is the right way to deal with
pre-computed data. If it were so, what would be resources for?
Getting 3.0 out is more important than fighting over this, so I'll drop the
case.
For "more security" with the literal arrays, you can just add a call to "clone"
instead of returning a reference to the internal arrays in
"FastMasthLiteralArrays". This will create an additional copy but is likely to
be faster than a sequence of getter calls (although this is again a trade-off
likely to be below the significance level of most applications...).
> FastMath has static code which slows the first access to FastMath
> -----------------------------------------------------------------
>
> Key: MATH-650
> URL: https://issues.apache.org/jira/browse/MATH-650
> Project: Commons Math
> Issue Type: Improvement
> Affects Versions: Nightly Builds
> Environment: Android 2.3 (Dalvik VM with JIT)
> Reporter: Alexis Robert
> Priority: Minor
> Fix For: 3.0
>
> Attachments: FastMathLoadCheck.java, LucTestPerformance.java
>
>
> Working on an Android application using Orekit, I've discovered that a simple
> FastMath.floor() takes about 4 to 5 secs on a 1GHz Nexus One phone (only the
> first time it's called). I've launched the Android profiling tool (traceview)
> and the problem seems to be linked with the static portion of FastMath code
> named "// Initialize tables"
> The timing resulted in :
> - FastMath.slowexp (40.8%)
> - FastMath.expint (39.2%)
> \- FastMath.quadmult() (95.6% of expint)
> - FastMath.slowlog (18.2%)
> Hoping that would help
> Thanks!
> Alexis Robert
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
