TeeChart for Java very slow on Android

[gusg]

I need some suggestions to speed TeeChart for Android up a bit. I have the source version and am targeting Android 2.2 API 8 for a dedicated display (see http://www.touchrev.com/products/nimble/7-inch/). Without doing anything other than just instantiating a chart class with chart = new TChart (this); takes nearly 10 seconds the first time it is run. Adding a bar to the chart is not very speedy either. I need to use only a bar class and a fast line. I did try the suggestions in the post titled "How to use fragments of source code in Java" and removed a big chunk of stuff from styles and did not notice a significant improvement.

Gus

[Marc]

Hello Gus,

Please could you confirm if you experience the same performance issues with the TeeChart demo that's included with the product.

With thanks.
Regards,
Marc Meumann

[gusg]

Tested with the demo and get the same results. Sorry it took a while, I had only tested the demo on the simulator until now and always assume that will be slow. I was on the road yesterday and did not have hardware with me. The very first iteration of the line "chart = new TChart(this);" which is line 138 in ChartView.java takes about 10 seconds. Seems like an awfully long time for what appears to be happening here. Once the app is running, coming back again (assuming the garbage collector hasn't zapped it) is much faster.

Gus

[Marc]

Hello Gus,

I assume the time delays you report are at debug time as you're able to identify where the lag occurs. Re-running a debug session over the test code-line you mention, I can confirm that it runs very slowly in debug mode, more than 20secs with the emulator on this test machine, but only about 4 seconds to a device (Nexus 7). When running the installed application on the device in release mode (installing the apk) there is no perceptable time lag at all to loading the Chart. Is that what you see?

As the time difference taken debugging between emulator and device are so marked it seems to indicate that the time delay is directly relative to the device being tested. With respect to the emulator, time there can probably be improved upon by increasing the RAM allocated, ie. this post:

http://stackoverflow.com/questions/1924 ... -emulation

Bumping the amount of ram on a honeycomb AVD from 256M to 1GM resulted in huge speedup. It was taking ~1 minute to $ adb install -r foo.apk; now it take 4 seconds. I think the emulator was going into swap!

Looking around the web there are other posts of a similar nature that may be of help to you.

With respect to a physical device itself it may be that the device contains some optimisation parameters, but I don't have the experience to be able to comment on any specific feature.

Whilst debug speed is important, perhaps more important here is that the release mode apk runs at an acceptable level.

Regards,
Marc

[gusg]

I really don't care about the simulator, almost all of my testing will be on an actual device. A bit more testing, first instantiation of a chart takes 15+ seconds on our hardware, subsequent opens of the activity with the chart in it take about 1 second +/-, that is probably acceptable. I will probably have the initial load of the app visit any activities with a chart in them to get past that, this way the only slow part will be when it is first started. This is an embedded app and will always run on only this one specific piece of hardware, and will never go into sleep mode, and no other apps including the Android launcher will ever be visible to the user. The more concerning part is how long a repaint takes when I add a bar to the chart. I have not figured out how to directly time the repaint with the debugger yet, however observation is that it takes about a second. I was very much hoping to add bars to the chart in real time, but at a second per repaint this is way too slow. Series.add () is fast, it is the repaint that seems to be taking all the time. We need to be able to add up to 4 bars per second at times. Any suggestions are greatly appreciated at this point.

Gus

[Yeray]

Hi Gus,

Excuse us for the delay here.
We are aware that TeeChart Java for Android repaints are a bit slow and this is a thing we hope to be able to improve in next versions.
In the meanwhile, if you want to send us your application, we'll be glad to take a look at it and see if we can find something that could improve the response in it.

[gusg]

Thank you for the reply. Our app needs to display a bar chart of pairs of data as they happen. The pairs could occur as frequently as twice a second or could be separated by many seconds per pair. The two pieces of data in the pair may be separated from each other in time by several hundred milliseconds or could be almost simultaneous. This is real time data. I have tried setting setAutoRepaint to false on receipt of the first of a pair of data and waiting long enough that the second has had enough time to be available and painting both at the same time. This does avoid having two repaints for each pair of data, however does slow the response down by the delay time. Right now, I am timing response by how long it takes for the screen to refresh after setting setAutoRepaint to true. For what we want to do, this time is much too long, we would prefer that the bars for a pair of data show up in a few hundred milliseconds at the very most. This app is an update and combination of a couple of others that were originally developed with the Delphi VCL version of TeeChart running on a Windows PC. We are trying to get rid of the PC and run our app on a dedicated Android display built right into the product. At this point, the first question is, how long to a faster version? I had considered digging into the the source code to see if I could improve the repaint time a bit myself, however am a bit put off by the large number of compiler warnings that Eclipse produces when compiling it with my app, more than 700.

[Marc]

Hello,

We are reviewing performance aspects of the library. We'll get back to this thread with comments.

Regards,
Marc

[gusg]

Would it be possible to get a timeline for this? We, like everyone else I am sure, have a project with a deadline.
Gus

[Marc]

Hello Gus,

We can't give you a timeline yet. We are working on this as a high priority task but there is still some investigative work to complete before we are able to give you any detailed information.

As an interim measure you may find that you can optimise some elements of performance by disabling text or Pen where not strictly required or by selecting a Series type such as Fastline that has already had optimisation work done to it. With respect to any progress made here, will offer you a test version as soon as we can offer something to work with.

Regards,
Marc

[crni]

I had similar problems with performance on Android 2.3 and lower. It turned out the problem was not in TeeCharts but in SimpleDateFormat.

Since dates are often used on charts, this might be the reason for TeeCharts to appear slow.

It actually turned out that creating a new instance of SimpleDateFormat and calling parse() on it took cca 2 seconds. Since SimpleDateFormat is not thread safe and I needed thread safety, I had to create a new instance each time. On Android 4+ everything works fine.

There are some notes about it, like this one:
http://andmob.wikidot.com/faq-simpletimeformat

I'll just try JodaTime instead, I guess it will solve my problems.

[gusg]

Thank you much for the hint, however at this point, we are not doing anything with dates, but most likely will in the future although probably not on a chart. My speed problem is just adding simple pairs of bars to a chart with float y values and integer 1,2,3... x values. Takes over a second for each bar added.

[Marc]

Hello Gus,

Are you able to send us a sample application that comes close to reproducing what you are doing. The time delays you describe adding the bars to your application are beyond what we achieve in tests here. It may be that there's some configuration aspect at play here that we've not yet identified.

With thanks.
Regards,
Marc

[gusg]

Two potential problems here. I can not post a complete app on a public forum, trade secrets and all that stuff. If you have a private way, that may be acceptable. Second, the data that adds the bar(s) is generated by hardware on the other processor in this design and sent to the Android display over a serial port. Without that other half to generate the data, it would be difficult to see it happen. Perhaps I could alter it to generate data locally by some other means, make me some suggestions here. Note that this app will only ever run on the one piece of hardware we are using. See info in the first post in this thread. Note that the demo seems to perform about the same way as our app does on this hardware.

[gusg]

More info. On further testing, I notice that series.add(v1, v2, Color.blue); executes very quickly. I have set chart.setAutoRepaint (false); before doing this and executed setMinMax before setting AutoRepaint to true again and then doing a chart.invalidate(); to get it to repaint. The big delay happens after this point. It appears to bog down the whole app to the point that nothing else seems to be keeping up while this is going on. I also notice that even after my app has painted the chart and is idle, scrolling by touch has similar delays. Drag the chart left or right with a finger and there is a long noticeable delay after dragging before it actually moves.
Gus