I have a containercontrol. It has a property called spFolderItem, which is a folderitem.
The containercontrol is also the parent of a method. Within that method I set spFolderItem to Nil, and then, a bit later on, I do this:
spFolderItem = New FolderItem( spFolderPath, FolderItem.PathTypeNative )
where spFolderPath is a String within the method. There are tests to make sure that spFolderPath is a native path.
One of our customers has reported that that line (as evidenced by vast amounts of logging code) can be insanely slow. The logs have reported it taking anything from 191 microseconds right the way up to 102551155 microseconds (yes, 102.5 seconds) to run that single line (both with the same path). He’s only reported it on drives running on external Thunderbolt drives, but I’m not sure if that’s a red herring. He’s on a Mac.
This didn’t happen when we were using .AbsolutePath (with the absolute path, of course), but we’re not using that any more because it’s been deprecated.
Has anyone seen this before? Can anyone make any suggestions as to what we might be able to do to make this snappy again? (I can’t find any MonkeyBread function which sets a folder based on a native path, but I’d be happy to use one if there were one…?)
I have an external TB drive and when its spun down things take a while
Just opening a finder window that browses volumes can be slow
I dont even have to try & save to them or browse them
They just need to be spun up just in case
It shouldn’t, which makes this a very interesting bug. If possible, could you get a sample of the process from your customer when it’s in this hung state?
I can certainly try; can you tell me what I need to tell him to get this? He’s (rather understandably) very frustrated that it’s not working properly, and so I need to give him really clear instructions which he can follow first time.
Thanks!
Hamish
@Michel Bujardet No, I haven’t; we are using NativePath because that’s what is advised instead of using AbsolutePath. We’re storing NativePaths in a database, so there’s no easy way to convert to a ShellPath without going via a FolderItem, which would give us the same problem.
So I apologise for this question, since based on the above the answer is ‘yes’… however…
Is it definitely that line, and not the next one where you create or open the file that you reference?
Because you might be running into virus checkers.
It’s definitely that line. We start logging the line before it, and we stop logging the line after it. There is only one line within the logging steps!
As your user if In System Preferences > Energy Saver they have “Put hard disks to sleep when possible”
That might explain some of this
The system has to do a fair amount of work to wake them up
Linking a folder item with an Alias can be slow (sometimes very very slow).
Most certainly when the Alias is pointing to the original file on a external drive.
I’d have him actually send a screen shot of that pane in his preferences
We also get “No thats not that way in my preferences” and the screen shot shows it is from time to time
At least that way you know he’s actually looked at it rather than relying on his memory
I have a question for you: You say that you’re setting the folderitem to NIL, then trying to recreate it later. May I ask why? Unless the application is winding down and relaunching; it might be better if you don’t.
I don’t know if Xojo is using NSURL underneath; but Apple’s docs explain that a NSURL creation is expensive, and try to avoid creating and releasing on the same URL.
The other thing I wonder; a link to remote disk (not physically plugged in) can cause the OS to to mount the remote disk; just to check to see if the file exists. I wonder if he has an alias to a remote disk, so when the Xojo app is hitting the alias, perhaps the OS is also checking the file on the remote disk?
The two other things that can cause file access to drag to a crawl; is spotlight deciding that you’re not busy and it re-indexes a large amount of files (I hate this). Or when a drive has gone bad.
