This has been discussed before. SimpleDateFormat is not thread-safe, so the non-GWT editions of Restlet take the safe but expensive approach of creating a SimpleDateFormat instance for each use. (GWT edition does it differently; I don't know what the performance characteristics are there.)
For the common case of "yyyy-MM-dd'T'HH:mm:ssz", there's an optimization that look likely to perform better, org.restlet.engine.util.InternetDateFormat. This might have been added very recently, so it might be worth checking if you get the same performance characteristics with a more recent Restlet version. If Android's DateFormat is better for Android edition, great, but that still leaves the other editions out in the cold. The approach I'd favor would be to cache instances thread-locally indexed by format string, expiring stale entries and using a soft or weak reference map to prevent references from getting in the way of garbage collection. Writing such a cache from scratch is fiendishly hard, however. Not the for the first time I wish Restlet could take advantage of Guava, which contains all the machinery you'd need for this in its MapMaker<http://guava-libraries.googlecode.com/svn/trunk/javadoc/com/google/common/collect/MapMaker.html>class. Failing that, though, what about making the provision of date formatting and parsing pluggable? --tim On Wed, Feb 16, 2011 at 6:30 PM, fritzr <[email protected]> wrote: > Hi togehter, > due to the fact that android itself has only the HTTP4 client and I don't > want to access some REST services I decided to replace my old code (http4 > client with manual json deserialisation) with the android restlet version. > > today i spend a lot of time with the profiler to figure out, why the > restlet > approach is so extremly slower than my old approach. > > I figured out, that in contrast to my own solution, restlet reads, sets and > transfers header parameters in the requests and responses. There are some > fields containing dates such as the field "Expires". Anyway, it seems to be > a known bug in android that all SimpleDateFormat method calls are very > slow. > > To give one example: > There is a method called ClientAdapter.toSpecific() which calles > HeaderUtils.addGeneralHeaders() which calles DateWriter.write()... The > stack > ends in the call SimpleDateFormat.format(). > > The execution now takes always some seconds, which is about 10 times slower > than the http4 aproach. > > Some numbers: > 02-16 23:43:38.775: INFO/app(12413): sendLocation with httpClient took 874 > ms > 02-16 23:43:42.015: INFO/app(12413): sendLocation with restlet took 3204 ms > 02-16 23:46:20.665: INFO/app(12413): sendLocation with httpClient took 655 > ms > 02-16 23:46:24.005: INFO/app(12413): sendLocation with restlet took 3301 ms > 02-16 23:50:40.825: INFO/app(12413): sendLocation with httpClient took 656 > ms > 02-16 23:50:44.855: INFO/app(12413): sendLocation with restlet took 4003 ms > 02-16 23:51:06.775: INFO/app(12413): sendLocation with httpClient took 612 > ms > 02-16 23:51:10.005: INFO/app(12413): sendLocation with restlet took 3192 ms > > > Because the header modification stuff is somewhere in the deep of restlet, > it is not easy to override. > > Any ideas how to handle this problem? > -- > View this message in context: > http://restlet-discuss.1400322.n2.nabble.com/Reading-setting-date-header-fields-is-extreme-slow-on-android-tp6033977p6033977.html > Sent from the Restlet Discuss mailing list archive at Nabble.com. > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2704886 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2704889
