Thanks for the update!
I just sat down and put together a JNI routine that uses strftime in C and I
took my formatting from 50%+ of the routine that was populating my view down
to 0.2%. I would call that a significant improvement! Here is the code I
used:
---- Java Class ----
public class JNIUtils
{
private static native String dateFormatJNI( String sFormat, long millis
);
static
{
System.loadLibrary( "jniutils" );
}
public static String dateFormat( String sFormat, long lTime )
{
return dateFormatJNI( sFormat, lTime );
}
}
---- C File ----
#include <jni.h>
#include <time.h>
JNIEXPORT jstring JNICALL
Java_com_company_project_jni_JNIUtils_dateFormatJNI( JNIEnv *env, jclass
cls, jstring format, jlong millis )
{
time_t javaTime = millis/1000;
struct tm * timeInfo;
char buffer[32];
const jbyte *str;
str = (*env)->GetStringUTFChars( env, format, NULL );
timeInfo = localtime( &javaTime );
strftime( buffer, 32, str, timeInfo );
(*env)->ReleaseStringUTFChars( env, format, str );
return (*env)->NewStringUTF( env, buffer );
}
I am new to JNI, so I'm not sure how clean this code is. I know C/C++, but
I'm getting use to how you have to deal with the Java-to-C layers properly.
Regardless, this runs about 250x (or more) faster than the built-in Java
version.
You may want to check this out if you feel like getting the NDK installed
and configured to where you can build the libraries.
Steven
Studio LFP
http://www.studio-lfp.com
On Monday, October 17, 2011 5:35:52 PM UTC-5, tlegras wrote:
>
> I do confirm using Date is about 2x faster.
> But I tryed using Calendar as Date.getHours/Minutes etc. is deprecated. The
> good news is that is even faster: Almost 6x faster than my original which
> was using DateFormat.format
>
> Here is my code:
> private static Calendar sTmpCalendar = Calendar.getInstance();
>
> // convert timemilli to HH:mm string
> public static CharSequence Time2DisplayString(long timemilli) {
> sTmpCalendar.setTimeInMillis(time);
> int hours = sTmpCalendar.get(Calendar.HOUR_OF_DAY);
> int minutes = sTmpCalendar.get(Calendar.MINUTE);
> return ((hours<10)?"0":"")+hours+":"+((minutes<10)?"0":"")+ minutes;
> }
>
>
>
> 2011/10/14 Thierry Legras <tle...@gmail.com>
>
>>
>> Thanks Steven! I will try that.
>> As Date.getHours() etc. methods are mentioned as deprecated. I will check
>> with Calendar class as well if it is still faster than DateFormat.
>>
>> Thierry.
>>
>>
>> 2011/10/14 Studio LFP <studi...@gmail.com>
>>
>>> It is slow and so is String.format(). I've been messing around with it a
>>> bit and here is a *rough *sample I tested:
>>>
>>> private static final String DATE_AM_PM[] = { "am", "pm" };
>>> private static Date dFormat = new Date();
>>> private static int iHour, iAMPM;
>>>
>>> public static String formatDate( long lTimestamp )
>>> {
>>> dFormat.setTime( lTimestamp );
>>> iHour = dFormat.getHours();
>>>
>>> if( iHour == 0 ) { iHour = 12; iAMPM = 0; }
>>> if( iHour == 12 ) { iAMPM = 1; }
>>> else if( iHour > 0 && iHour < 11 ) { iAMPM = 0; }
>>> else if( iHour > 12 && iHour < 24 ) { iHour -= 12; iAMPM = 1; }
>>>
>>> return dFormat.getMonth() + "/" + dFormat.getDay() + "/" +
>>> (dFormat.getYear() + 1900) + " " + iHour + ":" + dFormat.getMinutes() +
>>> DATE_AM_PM[ iAMPM ];
>>> }
>>>
>>> As I said, it is rough and doesn't even format the output fully.
>>>
>>> I tossed this in my application and used it a bit for a speed test and
>>> this takes up half the time as the formatting routines do. Funny thing is,
>>> it has nothing to do with the date part. It seems the formatters are using
>>> a
>>> StringBuffer and some replace functions in the StringBuffer and that is
>>> what
>>> is slowing it down. I may try to work up a JNI replacement and see if some
>>> sprintf or fprintf action fix the issue but it may not because of the extra
>>> layer.
>>>
>>> Steven
>>> Studio LFP
>>> http://www.studio-lfp.com
>>>
>>>
>>>
>>> On Thursday, October 13, 2011 4:26:32 PM UTC-5, tlegras wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am optimizing the critical parts of my code, and I coming to some
>>>> ResourceCursorAdapter bindView method.
>>>> Though the method is quite long, I saw on traceview that only 2 lines
>>>> are taking 40% of the time in traceview; those are call to DateFormat:
>>>>
>>>> ((TextView)view.findViewById(**R.id.EPG_list_item_hour)).**setText(
>>>> android.text.format.**DateFormat.format("kk:mm",**beginTimeMilli) +
>>>> " - " +
>>>> android.text.format.**DateFormat.format("kk:mm",**endTimeMilli));
>>>>
>>>>
>>>> So just curious: Is there any more efficient way to transform a
>>>> "timeMillisecond" time to a date string (in my case hour/minute)?
>>>>
>>>> Thierry.
>>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Android Developers" group.
>>> To post to this group, send email to android-d...@googlegroups.com
>>> To unsubscribe from this group, send email to
>>> android-develop...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/android-developers?hl=en
>>>
>>
>>
>>
>> --
>> Thierry.
>>
>
>
>
> --
> Thierry.
>
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
android-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
