Jump to content
Sign in to follow this  
Sherlock

Anyone else notice performance issues for iOS from 10.3.2 compilations?

Recommended Posts

I have an FMX project that is mainly reading csv files and turns the numerical data into plots (more detailed: measurements over time, with 4 measurements per second). It has been performing "so so" for iOS which caused me to not leave beta phase. Windows performance is way better. That was 10.3.1.

Now in 10.3.2 I see almost the same performance in the iOS simulator (still iOS 10.3 only, thought that was being fixed in this release), but on the real device (5th gen iPad) it is way, way slower. I will of course enter lots of stopwatches to check what exactly is costing time, but before that I just wanted to check if anyone else has noticed this as well.

 

Cheers

Share this post


Link to post

So far I have better perfomance on iOS, no matter 10.3.1 or 10.3.2, compared to Android, which is still behind.
But I couldn't really notice any big difference between the 10.3.1 and 10.3.2, also when using approximately same datarate as your,
with storing into Sqlite, showing Chart, showing each data point on the screen.
Ok, usually the datarates are lower, about 1 / sec., but I can also process the fastest channels and  IoT devices with 0.25 sec. w/o stucking.


The data comes in via Bluetooth LE, into a threaded ringbuffer, then getting processed chunk by chunk in a dedicated analyser,
abnd the result is put into a special TMessage and sended to any subscriber in my app
(which can up to 4-5 subscribers at a time (Sqlite table storage, Preview display,  Chart view, debug logging, text to speech, etc.).

I must confess that I have already made larger structural changes between 10.3.1 and .2, because of improving Android system mainly,
so from these improvements iOS also gains a lot.
But my early tests in a 1:1 same configuration for both IDE verisons showed no big, noticeable differences.

Share this post


Link to post

OK, I finally got around to finding out what the problem is. turns out string comparisons got massively slower from 10.3.1 to 10.3.3 for iOS.

Here is what I did approximately 6000 times:

  function QualityToInt(aQuality: string): ShortInt;
  begin
    if aQuality = rsPoor then
      Result := 0
    else if aQuality = rsAcceptable then
      Result := 1
    else if aQuality = rsGood then
      Result := 2
    else
      Result := 0;
  end;

Where rsPoor etc. are defined as resourcestring. This (plus some other stuff) took 100 seconds.

Changing that to filling a TDictionary with the appropriate pairs once and doing a

    if not QualityDict.TryGetValue(aQuality, Result) then
      Result := 0;

instead not only improved iOS performance (now 20 seconds) but the Windows version is noticeably faster too.

 

So...granted the latter is better code. But still: What got broken along the way?

  • Like 1

Share this post


Link to post

The original code in QualityToInt causes a System.LoadResString for each "case" it checks every time you call that method and System._UStrEqual for the equals check.

Neither of those two methods have changed between those versions according to the diff I just did.

 

However LoadResString calls quite a number of other functions that I did not check for changes.

 

I would say a dictionary is pretty much overkill here for those 3 strings - it only is faster because you eliminated the (as I assume) LoadResString calls every time.

Try initializing values you compare to only once instead of comparing against the resource strings. I am pretty sure that will beat the dictionary.

Edited by Stefan Glienke
  • Like 2
  • Thanks 1

Share this post


Link to post

In addition to what @Stefan Glienke pointed out, there is a problem with your prototypes, your function does not change aQuality param so why you're passing it by value ? Also you're adding extra-no-sense comparison 

if aQuality = rsPoor then Result := 0 // you may remove this one !
...
else Result := 0; // rsPoor covered here !

 

  • Like 1
  • Thanks 1

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×