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
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.
@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.
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.