Performance, Compatibility, Links and Aliases
I'd like to diverge a bit from the tips and tricks to talk a little about an issue I am running into in developing LabVIEW on Mac OS X. In the Mac OS Classic version of LabVIEW, we had a magic feature that would treat an alias anywhere in a path as transparent. This allowed you to move things around, replace the original with an alias and LabVIEW would treat the alias as the original item (folder or file).
When Mac OS X came along, we switched to Apples newer Carbon APIs that allowed for long file names. We also had a new type of alias, called a symbolic link (UNIX form of alias). So now, if an alias or symbolic link were to be anywhere in the path, LabVIEW should just treat it as the original item.
In LabVIEW 7.x, our first port of LabVIEW to Mac OS X, we found that we would handle symbolic links by accident, but aliases no longer worked. In LabVIEW 8.0, we added the ability to handle aliases as well, at a cost. Launch and Mass Compile, file intensive operations, were spending around 30% of their time in converting a path into a file system representation (FSRef). I reworked the code for the next major version of LabVIEW down to 7% to 9%. This has a noticeable impact on launch and mass compile, but I think we can do better.
Here are the options I am weighing:
1. By default, disable alias support (you can set a token in the preferences file to re-enable it).
2. Change the path format to UNIX style instead of HFS Mac Classic style
UNIX: /Users/johnd/Desktop
HFS: Macintosh HD:Users:johnd:Desktop
Option 1 above doesn't give us as much of a boost as I was hoping. Another Mac developer here would really like to see option 2 implemented. Here is the theory behind the possible speedup from option 2.
A large part of the time we spend in file operations is converting a LabVIEW path (HFS Classic Style) to a file system representation (FSRef) so we can call the OS APIs. If we instead just convert the path to a string (which is just one step in the HFS method), but a UNIX string, and then call UNIX APIs, the theory is that it will be much faster.
In order for this to be the most efficient, we would have to change the string format of paths on the Mac so they would be UNIX style instead of HFS Classic style. That means any string constants of paths would break.
So we are left to puzzle over compatibility vs performance trade-offs.
If you have concerns or an opinion on this post, please post a comment below.
When Mac OS X came along, we switched to Apples newer Carbon APIs that allowed for long file names. We also had a new type of alias, called a symbolic link (UNIX form of alias). So now, if an alias or symbolic link were to be anywhere in the path, LabVIEW should just treat it as the original item.
In LabVIEW 7.x, our first port of LabVIEW to Mac OS X, we found that we would handle symbolic links by accident, but aliases no longer worked. In LabVIEW 8.0, we added the ability to handle aliases as well, at a cost. Launch and Mass Compile, file intensive operations, were spending around 30% of their time in converting a path into a file system representation (FSRef). I reworked the code for the next major version of LabVIEW down to 7% to 9%. This has a noticeable impact on launch and mass compile, but I think we can do better.
Here are the options I am weighing:
1. By default, disable alias support (you can set a token in the preferences file to re-enable it).
2. Change the path format to UNIX style instead of HFS Mac Classic style
UNIX: /Users/johnd/Desktop
HFS: Macintosh HD:Users:johnd:Desktop
Option 1 above doesn't give us as much of a boost as I was hoping. Another Mac developer here would really like to see option 2 implemented. Here is the theory behind the possible speedup from option 2.
A large part of the time we spend in file operations is converting a LabVIEW path (HFS Classic Style) to a file system representation (FSRef) so we can call the OS APIs. If we instead just convert the path to a string (which is just one step in the HFS method), but a UNIX string, and then call UNIX APIs, the theory is that it will be much faster.
In order for this to be the most efficient, we would have to change the string format of paths on the Mac so they would be UNIX style instead of HFS Classic style. That means any string constants of paths would break.
So we are left to puzzle over compatibility vs performance trade-offs.
If you have concerns or an opinion on this post, please post a comment below.
posted by Marc | 6:59 AM
2 Comments:
Hi Marc, for me Unix style will be better. It will be more "professional" and more close to Os X file system.
More over HFS style is almost mean "old" MacOs9 and Mac OS X is already 5 years old…
odjau
I also would prefer the unix style formatting of filenames.
Many of the other scientific programs I use on Mac OS X have moved to this style and I find it much more streamline and coherent for me when I have to switch between an app and say X11 or Terminal.
Post a Comment
<< Home