Anyone else notice performance issues for iOS from 10.3.2 compilations?

[Sherlock 663]

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

[Rollo62 536]

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.

[Sherlock 663]

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?

[Stefan Glienke 2002]

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 August 23, 2019 by Stefan Glienke

[Mahdi Safsafi 225]

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 !

 

[Sherlock 663]

Thanks, guys. I will give those hints a go.