Reading file meta data with Xojo is 3.4x slower than doing it with declares.
Tickling my own personal backup application, optimizing my routines showed no visible improvement in speed, I started to conclude that the bottleneck may be hardware.
Until I had the idea to try replacing folderitem.modifiedDate, folderitem.length, isAlias, isFolder with NSURL declares…
OH BOY! It went from taking 749 ticks to scan and compare 77k files, down to 221 ticks.
So if scanning files is your thing, look for NSURL resourceValuesForKeys:error:
2 Likes
This is actually great news as far as I am concerned. These numbers are using a Thread, running in the Xojo IDE. So the compiled app should get better numbers.
It also means once re-written into Swift and using proper pre-emptive threading, instead of co-operative, it should get even faster!
Your finding will actually improve one of my apps, which searches for files and folders extensively. Thank you.
1 Like
You have switched multiple requests for file properties with a single request to retrieve multiple properties.
I know Xojo folderitems can be slow but I don’t think this is a Xojo inefficiency as you would have similar overheads in Swift of Objective C if you performed individual requests.
The difference is that in Swift or Objective-C it is much easier (if you know the language) to use this function, which has been in the macOS since version 10.6 (2009).
The only option that Xojo provides you is inefficient, but unless you look for it, you’ll never know and think your app is slow because of other factors.
2 Likes
In Objective C, Swift, C++ with QT and Java I don’t have this behavior but in Xojo. What do you mean what that means? That Xojo is doing all stuff right and the others all wrong? Xojho File handling is outdated and runs slow. That you need to accept even if you don?t want to. Also the String handling, the Database Connecting, the database use (makes no difference using MB or original, it is at the end slower than the here used solutions named QT with C++ and Java Swing and also JavaFX. So I can’t get how you try to project theese stuffs on other languages to say: look here, xojo is good, all the others are as bad as Xojo.
1 Like
I never said Xojo was good or doing it right but feel free to make stuff up.
I agree that file system interaction should be improved so that bottlenecks like this can be removed. I just think that calling it a Xojo inefficiency is a little unfair.
I actually found a similar problem on MS-Windows about 3 years ago and logged an enhancement. My suggestion was the ability to retrieve multiple properties at once which is what you have have implemented in your macOS app.
There is no way to “stuff up”. As far as I can say: xojo is slower than c++ and java in String conversion, math operations and file operations. So nothing moire to say.
1 Like
I can’t believe I am saying this, but I am actually excited about re-writing this app in Swift. For a long time, I’ve felt so negative about having to re-write my apps, I know that I can always do better and improve my own code, but with moving to Swift, it gives me much more potential to build faster, smaller and more efficient apps.
And that appears to be making me happy right now.
2 Likes
One of my first RB projects was a simple 2D side scroller game. I maintained and improved it from RB 1.0 till when they dropped the SpriteSurface control. This means that I at least managed to get it onto Intel. These days I can play it on my Mojave VM, when I’m waxing nostalgic.
One of my daughters has repeatedly suggested that I revive it, and submit it to MAS, and maybe produce it for iOS as well. This might be a good “learn Swift” project for me. 
2 Likes
Yep. For me it was PHP. Welcome to the happy club!
1 Like
Yup. I started doing some proof of concept coding last week with Go/React using Wails. Since we use both at the job that pays the bills I made it part of my ‘professional development goals’ for the year. Love being able to kill multiple birds with one stone.
I’d imagine at some point I’ll do some blog posts about my experience with Wails but I’m not there yet.
4 Likes
I’m looking at fyne, but jnterested how you are getting on with wails
I looked at fyne but decided that Wails version 3 (at alpha status) was better and supports multiple windows. But I’m not married to Wails as I chose it solely on a feature set that’s not released and/or stable yet. I also figured that it will take a me a few months of tinkering and learning React/Typescript to become proficient.
2 Likes
fyne is great, but compared to the full possibility of a web ui interface still missing a lot.
It might be worth to keep an eye on tauri.app too. Currently they are only supporting rust as a backend (or node.js) but they mentioned from day one that ultimately they want to support other backends too, including GO.
But as we all learned from the green company, waiting for “something” can mean waiting for eternity 
.
Indeed. I decided to bite the bullet on Wails V2 because my learning curve on Go isn’t so bad now but I have a long way to go on React. I figure I will throw out whatever I create in a few weeks as I learn better ways to do everything.
2 Likes
I read that the other day. I think it totally makes sense - especially as you’re getting up to speed in a new language/library/framework. I’ve discovered even with the week of Wails work that my 2nd and 3rd versions were much better in each increment and the time was significantly less too. I’m sure there will be a point where I’m happy ‘enough’ with the code where I’ll keep a copy but until then the trash can it goes!
It seems that the React way of doing things is to come up with the UI skeleton using static code and then start stubbing in your dynamic code. So it doesn’t seem that much different from the Xojo approach other than there’s a lot more coding to get the basic UI set up. But everything is baby steps at this point.
1 Like