Profiling surprise with getting a version of folderitem.absolutepath

Profiling is so fascinating. Every time I use Instruments I find incredible stuff. My application has grown over the last 10 or so years. Therefore, it’s littered with rather elderly code.

After a customer complained that my app runs much faster on an SSD versus a normal IDE harddisk I started Instruments and was horrified to see the time spent in the following method:

[code]Function LongPath(extends theFolderitem as FolderItem) As String

'a version of absolute path with more than 255 characters

dim thePath(-1) as String

dim ParentFolderItem as FolderItem = theFolderitem
while parentFolderitem <> nil
if UBound(thePath) = - 1 or parentFolderitem.Name <> thePath(UBound(thePath)) then thePath.Append parentFolderitem.Name
parentFolderitem = parentFolderitem.Parent
wend

'reverse the array in place
Dim low As Integer = 0
Dim high As Integer = UBound(thePath)
while low < high
Dim temp As String = thePath(low)
thePath(low) = thePath(high)
thePath(high) = temp
low = low + 1
high = high - 1
wend

dim pathString as String = Join(thePath, “:”)
if len(pathString) < 255 then
Return theFolderitem.AbsolutePath
else
Return pathString
end if

End Function[/code]

I think this must be from Carbon or older times. After replacing this with a simple folderitem.nativepath the execution of my app sped up by about 30%. Does anyone have an idea why the code above is so totally slow??? I could also bet that this code wasn’t as slow in RealStudio times even with Cocoa.

Mac OS 10.9.3, Cocoa, Xojo 2013r4.

Well, Nativepath builds an CFURL for the FSRef inside the folderitem and than copies posix path from the CFURL object.

That is much faster than querying all the folder names upwards and the volume name to build the old style path.