you can test my example above.
i agree i had more speed hoped-for.
No need, I believe in you.
Its quite normal that integer assignment is faster than string. String is internally a object that carries data, while integer is basically primitive.
1 Like
Sure. But the trinary/inline version is faster than the traditional/multi-line version when assigning an integer; this is what I found interesting.
2 Likes
I get 1416 vs 2122 so yes I can reproduce that indeed.
So for peoples knowledge chest then so far as it stands then in place if (operator if) is faster for int, but slower for string, than multiline if’s.
1 Like
Interesting conclusion. Now t find out why the string if() is slower than the normal string if end if.
Whatever is done, the in-register optimization seems able to do good reuse of a register value but not a referenced value (pointer).
1 Like
As I always try to squeeze ever speed out of data processing I found another odd problem. But this is more related to the new API2.
Just do a test with the ‘old’ Instr() and the new IndexOf()
One of my apps uses INSTR a lot and the process takes a typical 32 seconds to do.
But when I change it to INDEXOF (which is the new API2) it takes a whopping 4min9secs.That almost 8 times slower.
When I use ComparisonOptions.CaseSensitive , it takes even longer: 5min42secs.
Now that’s bad and really needs optimisation.
So PLEASE do not remove INSTR (which is deprecated) until IndexOf is equally as fast (or faster).
1 Like
Please make a fb report, we should absolutely not get slowdowns in API 2.
Do you have a Feedback case number? I did a super simple test with a very short string. Even there IndexOf was 3 times slower.
1 Like
No, I have not created a FB of this. I just noticed this today when porting my code to API2 (and that I already reverted back to API1 
In fact, I do not care if the new API2 is slower, as long they keep API1 (which is obviously in some/many parts faster).
How do you expect the Xojo guys to fix problems? With telepathy?
<https://xojo.com/issue/66756>:
IndexOf much slower than Instr
4 Likes
I know and you are right. Thank you for creating the FB
Maybe I should add a FB about if() and if…then too but I don’t think they will/can improve this. Probably a feature instead of a bug.
2 Likes
Thank you for this.
I want to add when you do this in Swift, it doesn’t matter integer or string, if() is always a lot faster compared to if…then
So imo it is not good implemented (at compiler level?) in Xojo.
1 Like
@Christian_Schmitz had a nice blog article about speeding up string processing. Well worth reading.
2 Likes
I know and learned a lot of it too.
1 Like
what bout instrb v.s.the API 2.0 equivalent?
I believe that Swift defaults to immutables and its just a question of assigning a pointer, but Xojo defaults to mutables and needs “copies” of values, and making that takes clock ticks.
3 Likes
That was one of the hardest things to get my head around when learning Objective-C, immutable objects. I hated it.
2 Likes