Yeah, those functions basically look like this (from what I’ve been told):
Function IsEmpty(extends s as String) as Boolean
If s.Length = 0 Then
Return True
End If
End Function
So when you call the function, it’s doing the comparison you can already do, but you’re adding the execution time to find and execute the function.
Agreed, looks better, but … 
As someone with zero “real” coding background - some FileMaker, a bit of HTML, SQL and PHP - and no training at all, I’m just trying to learn what I can in my 60s, I find this fascinating and incredibly illuminating. I’ve gained more understanding about how Xojo works - and the reason some insist on doing things in a particular way - in this thread than in all the tutorials I’ve done so far. Thank you all!
My feeling is that the power of Xojo is the ability to develop across platforms. I could be learning to build my app on Xcode but then I’d have to start all over again for the Windows version. I guess, if I were developing a competitor to DaVinci Resolve or some Adobe product I might need to be a bit more concerned with code speed but I’m not.
It was added very recently.
String.LenB may be fast but I’m pretty sure String.Length is slow as is has to handle Unicode.
Probably, though now that I think about it, both Len and LenB are extension methods and likely to suffer the same slowness – compared to a simple comparison – as IsEmpty.
So…
Am I to read into all this that, whilst Xojo provides numerous .Methods and .Functions, it can be faster to write your own instance, because (so long as you write it efficiently) your own instance is specific to the task at hand, whereas the code built into Xojo has to cover a number of possible scenarios and therefore may be a little verbose?
I’ve worked with guys who write things like video codecs so I get where, at times, pure efficiency takes precedence over everything else but, for me as an ex film editor, I tend towards code that someone else after me can read, understand and edit.
I can see where Xojo has been developed to help developers to write their code as quickly as possible and that that can mean that, sometimes, that code doesn’t run as quickly as it might. It’s a tradeoff I guess.
That’s true enough. I would maybe word it like this:
Xojo can give you ease or speed, depending on what you need and how you write your code.
There are many tasks in many development languages that can be done differently for different results. That’s just as true here as anywhere else.
Fantastic!
For me, it’s ideal. Xojo means I can get a product to market more quickly (across all the platforms I want to release to) and my code should be written plainly enough that, should it prove successful and I can hire people to improve on my code for version 2.0 etc, there’s scope for those (pros) to whittle my code into something more streamlined.
Yes keep going. As long as it is working all is fine. You can always fine tune. And “readability” of your code is always good (for yourself and potentially others reading your code).
You made my (and my ego’s) day 
You mean you think it’s calculated at that time? I would have expected that as the string is created and evolves, the length is updated and kept with the string. There must be a header block of sorts with a String as with all datatypes (except perhaps integer etc) to keep things like Length, Encoding …
That’s anyhow an interesting question I would expect that the compiler is doing some magic behind the curtains but I am not sure … For instance could the compiler in theory translate isEmpty and = “” to the same coding … at least in theory it could …
Nothing stops the compiler doing such an optimisation - and doing the same with String.Length=0, too.
That may be one of the things that’s done when you set the Optimization Level to Aggressive, but I’d actually be surprised if it did on Default.
and as long as we don’t know what the compiler does it is utmost impossible to predict performance evaluations, as long as you don’t measure it, which is probably a waste of time for a simple string comparison …
and an explanation why these optimizations are running for an eternity - I am never using them, but that might be a mistake. I thought it only makes sense if you have an app with intensive float calculations etc … but again, I know too little or nothing what it really does 
All these things can be, and have been, tested. I don’t know that there have been any numbers posted for speed of these sorts of operations since the switch to LLVM, and I also don’t know what the compiler looks like. All I can do is speculate based on what’s been shared in the past and what I know of compiler design (which is very little, admittedly), and what I’ve seen in my own apps.
I do have some code with extensive loops that perform calculations and comparisons where speed is an absolute necessity. In those, I try to stay away from calling additional functions in the loop to squeeze the most speed I can out of the code.
I suppose I can provide a simplistic example. I had to write some code for a customer that generated a sort of heat map. When first writing the code I used separate functions that were called from within the drawing loop so that I could compartmentalize my code to make it easier to work on. When I had the functionality behaving as expected, I moved all of that code in to a single function. This was a few years back, but the speed increase was noticeable on the order of seconds for a massive image with tons of data.
same here, and with my kind of apps I never run so far in serious performance issues. Definitely not on a Mac. Sometimes on Windows, but those performance issues are more related to the GUI of an app than my coding (tons of controls), so little I can influence. And for controls etc. I haven’t seen any change when I switched the level to “aggressive”.