commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexis Robert (JIRA)" <>
Subject [jira] [Commented] (MATH-650) FastMath has static code which slows the first access to FastMath
Date Sat, 17 Sep 2011 20:59:09 GMT


Alexis Robert commented on MATH-650:

Hmm, you're right, if I understood correctly we were timing with different method (I was timing
with the Android profiler). I've done a little timing test which is this simple Java code

import org.apache.commons.math.util.FastMath;

public class Timing {
	public static void main(String[] args) {
		long start = 0, stop = 0;
		start = System.nanoTime();
		FastMath.pow(2, 64);
		stop = System.nanoTime();
		System.out.printf("time = %f ms\n", (float)((stop-start)/1000000.0));

I've launched this program both on my phone and on my laptop (Intel(R) Core(TM)2 Duo CPU T8100
2.10GHz, Linux 3.0, J2SE 1.7.0-b147), and I get the following results.

USE_PRECOMPUTED_TABLES = true (r1169543) :
- Computer : time = 33.472633 ms
- Phone : time = 12.847901 ms

USE_PRECOMPUTED_TABLES = false (r1169543) :
- Computer : time = 79.367081 ms
- Phone : time = 317.840576 ms

Old version before the bug report (r1160914 -- 2011-08-24 00:35:06) :
- Computer : time = 114.170425 ms
- Phone : time = 3518.310547 ms

The thing is that we must consider the fact that Android use an other virtual machine which
have really different bytecodes (even in structure, dalvik bytecode is register based), have
a different JIT (DalvikVM use a trace based JIT, and iirc Hotspot has a method based JIT),
and iirc they also have a different implementation of the standard library (Android use Apache
Harmony). So the fact that we may have slightly lower results on a phone on one use case with
such low timings doesn't seem me so strange.

By the way, you asked for the use case. I'm developing an Android application using Orekit
so the user can have access to often used spatial dynamics computations right from its pocket,
like a specialized handheld calculator. These 4s is the time which the user has to wait with
a "Please wait ..." dialog, instead of having a instantaneous result (which the user expects
-- users are often more exigent for the loading time on a phone than on a computer, that's
completely psychological). That's even worse when there is additional data loading or computations,
where those 4s have to be added to the data loading/computation time. A response time with
the magnitude of 100ms is really perfect !

> FastMath has static code which slows the first access to FastMath
> -----------------------------------------------------------------
>                 Key: MATH-650
>                 URL:
>             Project: Commons Math
>          Issue Type: Improvement
>    Affects Versions: Nightly Builds
>         Environment: Android 2.3 (Dalvik VM with JIT)
>            Reporter: Alexis Robert
>            Priority: Minor
>         Attachments:,
> 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.
For more information on JIRA, see:


View raw message