Wow nice! I haven't tried JNI before as well and I could not imagine it
would be interesting for such small functions.

In my case though I will stick to Calendar use as the time spent for time
formating is now little enough compared to the remaining parts. Si I won't
gain significant in further optimization.


2011/10/18 Studio LFP <studio....@gmail.com>

> 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)).**setTe**
>>>>> xt(
>>>>>     android.text.format.**DateFormat**.format("kk:mm",**beginTimeMilli
>>>>> **) + " - " +
>>>>>      android.text.format.**DateForm**at.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<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
>



-- 
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

Reply via email to