commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gilles (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
Date Wed, 30 Nov 2011 00:31:40 GMT

    [ 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

        

Mime
View raw message