Performances problems upgrading from 2.2.1 to 2.5


I upgraded from 2.2.1 to 2.5, after this upgrade zommig/panning with 80K data point is really slow, while before I was very satisfied with performances. How can I do? I restarted the iPad, deleted application and nothing seems to change.

To be more precise, I copied the “Getting started” example and added my previous classes.

Moreover when I tap on a point I get this exception.

00   CoreFoundation                      0x32e2a2bb <redacted> + 186
    1   libobjc.A.dylib                     0x3acce97f objc_exception_throw + 30
    2   CoreFoundation                      0x32d748d9 <redacted> + 768
    3   GettingStarted                      0x000b09b7 -[SChartSeries invalidateBinContainingDataPoint:] + 78
    4   GettingStarted                      0x000c5a0b -[SChartCanvasOverlay handleSingleTapGesture:] + 754
    5   UIKit                               0x34d4fd89 <redacted> + 128
    6   UIKit                               0x34d173f5 <redacted> + 392
    7   UIKit                               0x34f04a39 <redacted> + 48
    8   UIKit                               0x34c3b82f <redacted> + 218
    9   UIKit                               0x34c3a293 <redacted> + 1274
    10  CoreFoundation                      0x32dff6cd <redacted> + 20
    11  CoreFoundation                      0x32dfd9c1 <redacted> + 276
    12  CoreFoundation                      0x32dfdd17 <redacted> + 742
    13  CoreFoundation                      0x32d70ebd CFRunLoopRunSpecific + 356
    14  CoreFoundation                      0x32d70d49 CFRunLoopRunInMode + 104
    15  GraphicsServices                    0x369252eb GSEventRunModal + 74
    16  UIKit                               0x34c86301 UIApplicationMain + 1120
    17  GettingStarted                      0x0006b17d main + 116
    18  libdyld.dylib                       0x3b105b20 <redacted> + 0


Hey Trapo,

I’ve also managed to replicate this performance drop between version 2.2.1 and 2.5.0. I’ve raised a task and notified our charts development team of the issue. Someone should get back to you about this shortly.

As the crash when you tap your chart’s points, we aren’t aware of this issue. I think the best thing to do would be to send your modified “Getting Started” sample in to with a reference to this forum post, and someone will be able to take a look first hand and get back to you.

Jan Akerman


I did as you said, thanks.


Hi Trapo,

I’m currently looking into your issue. It is starting to look like your crash may be related to some other rendering issues we have had raised recently, so thank you for getting in touch with us about this. I’ll keep you updated with any progress we make.

Jan Akerman


Hello again Trapo,

We’ve found the root of this issue, and we will have someone looking into a fix shortly. I’ve made a note to keep this thread updated with any progress on a fix.



Hi Trapo,

I just wanted to let you know that we’ve fixed this issue and it will be included in the next release. This should be in the next couple of weeks.

Thanks for reporting this!


Hi Jan,

thank you for your effort. I did not understand. Do you fixed the crash or the slowness problem?

(or maybe both? :slight_smile: )


Hi Trapo - I meant the selection issue. We will be investigating the performance issue shortly. I’ll keep you updated with the progress we make.



Hi Trapo,

We’ve investigated the performance change between the two versions and it turns out that some of it is caused by the overhead incured by the changes we made to our rendering engine to allow data streaming. We essentially put datapoints into bins, and only draw a bin if something has changed within it, allowing us to have a large number of points, whilst only redrawing sections of the chart.

We can increase the speed of the chart by changing the size of the data bins, so we have less bins. Generally, the smaller the bin size the better the performance for streaming, but the worse the performance for huge data sets. The larger the bin size, the worse the performance for streaming, but the better the performance for huge data sets.

Large data set bin size

I managed to achieve the best large data set performance by setting my bin size to be larger than my total number of points. This means there would be a single data bin. For example, if you have 80,000 points, make your bin size 100,000.

Streaming performance bin size

The default bin size for series is 64. This is the size we find works best for data streaming & general chart usage, but feel free to experiment with your own bin sizes.

How to change your bin size

Currently, you can’t change your bin size to anything greater than about 10,000 points. We’ve removed this restriction & we plan to be releasing sometime next week. When the new release is out, all you need to do to change your bin size is import the category SChartSeries+DataBins.h. This will expose the methods:

  • (NSInteger) numberOfDataPointsInBin;
  • (void) setNumberOfDataPointsInBin:(NSInteger)numberOfDataPoints;

When the release is out, follow the above advice on your bin size & you should see a performance increase. Could you give that a try and let us know how you find the performance increase?

We’re continuing to look at increasing the performance of the chart, but the above advice should be a large step in the right direction!

Jan Akerman



I’m using Shinobi chart with two line series and 36 datapoints and noticed [SChartCanvasRenderView drawRect] takes about 1097ms out of which Running  SChartGL::Drawer::renderTriangles(SChartGL::RenderData const&, int*, SChartGL::AnimationState const&) takes 636ms. Wondering how do I optimize my chart’s performance?