1
votes

So, I've been playing around with Core Plot (iOS, version 1.5) to see how well I can integrate into my app. I'm testing it on an iPad 3, which is usually my base device for graphics.

Instead of pasting a ton of code, here's the plot configuration:

  • 1 Graph, using the Plain White Theme
  • 1 Plot Space
  • 2 Separate Scatter Plots, 3 data points per plot.
  • 2 Axis:
    • XAxis: Range: Dec 2013, Mar 2014 (NSTimeInterval). 3 Labels, 3 Major Ticks and about 90 minor ticks (1 per day)
    • YAxis: Range: 0, 250. 3 Labels, 3 Major Ticks, 12 minor Ticks. YAxis Floats on Right side of graph.
    • Each Axis has 1 Title

So, generally my app sits at around 33-34 mb usage. It may spike up to 50 mb if displaying a few images, but generally it'll sit within the 33-34 mb range. However, loading up Core Plot jumps the memory to around 63 mb. If I enable scaling and pinch on the graph to scale it or I simply drag the graph around, memory usage spikes to ~ 143 mb and then settles back to 84mb. When I close the graph, memory drops to about 22mb, which I assume is because other caches have been cleared due to memory pressure.

Also, maybe related, pinching and dragging the graph is remarkably slow. Maybe averaging 2-3 FPS with drops to 2 SPF (seconds per frame...seriously).

It looks like Core Plot is taking an obscene amount of memory and is horribly slow.

Am I missing something or is this just the way Core Plot is? Unless I can speed this up and use a lot less memory, there's just no way I can use Core Plot in production.

Update
I have profiled my app using Instruments. There's not too much to say here except that all of the memory gain is in Core Plot objects (or derived from them). The Time Profiler shows that when I resize or move the plot, most of the time is being spent in one of various core plot rendering methods originating from a drawInContext: method. Ironically, the first line in that method is self.useFastRendering = YES;.

I will add that the plot is almost full screen. I have a couple other controls to edit Plot fields, graph type, etc, but that's it.

To be honest, I was kind of hoping I'd miss some kind of property related to performance, but that doesn't seem to be the case. Core Plot is probably fine for static graphs, but it lags behind in interactivity and performance.

I spent some time looking over the Shinobi Controls and checking out their iOS demo. This is exactly the kind of interactivity & performance I want in my graphs. But I'm leery about including expensive, closed, 3rd-party code in my app...

Likely I will spend time creating my graphs by hand.

1
Core Plot does have known performance issues, especially on older hardware like the iPad 3, but this sounds pretty extreme. Have you profiled the app to see where the bottlenecks are? - Eric Skroch
Yeah, I profiled the app (see above). The problem lies almost entirely in Core Plot. - Aaron Hayman
I am having the same issues Aaron.. Simple pie chart.. 3 sections.. I am watching for device orientation notifications and the memory goes through the roof, crashing the app after a few rotations of the device.. Was looking at Shinobi charts too.. Might have to fork out for Shinobi myself..! - jheneghan

1 Answers

0
votes

Unfortunately Core plot is a very slow library which can only handle a few hundred data-points before memory and CPU usage gets out of hand.

There were other chart components which were able to handle big data much more efficiently. Have a look at https://stackoverflow.com/a/45589678/303612 for more info