Close all your apps, open the terminal and type in "sudo update_prebinding -verbose -root / " Enter your password and press return. This takes awhile so be patient. This will speed up MacOS X slightly, it is doing just what it does when you update to a new version or install the dev tools. Note: Xoptimize is a GUI front end to this command so there is no need to download it.
Speed Up OS X!!!! (with smoking weed)
- Thread starter ScottW
- Start date
It doesn't really speed anything up. Im guessing that you upgraded to 10.0.4 and when you do that it does "sudo update_prebinding -verbose -root /" When you installed the Dev tools it does the same thing. Since you had already just done it you will not see a speed increase.
ezra
Super Organism
"I did....0.4 didn't seem to add much speed. but devtools? wow. immediately noticeable. "
Which ever you installed first will give you the "speed" increase. The 2nd one installed is just doing what the first did and you won't notice any increase because you already updated the prebinding.
Which ever you installed first will give you the "speed" increase. The 2nd one installed is just doing what the first did and you won't notice any increase because you already updated the prebinding.
tismey
Official Bartender
Peppermg - You seem remarkably certain about what happened on MY system, despite the fact thatI installed 10.0.4, I noticed no difference in speed, I installed devtools a day or so later, and I noticed an increase in speed, and you were nowhere to be seen...
I appreciate that you probably know a great deal more than I do about the foundations/principles/whatever to OSX, cos I know next to nothing about it, but I can categorically say that MY MACHINE HAS BEEN FASTER SINCE I INSTALLED THE DEVTOOLS UPDATE. I'm not trying to explain WHY, just agreeing with the post that Admin started this thread with.
It may not fit in with what you perceive to be the actual under-the-bonnet effects that this install had, and it may not tally with all that you know and hold dear, but I think it's fairly cocky of you to insist that I (or Twister) WON'T notice any speed increase. Because I did. So there.
I appreciate that you probably know a great deal more than I do about the foundations/principles/whatever to OSX, cos I know next to nothing about it, but I can categorically say that MY MACHINE HAS BEEN FASTER SINCE I INSTALLED THE DEVTOOLS UPDATE. I'm not trying to explain WHY, just agreeing with the post that Admin started this thread with.
It may not fit in with what you perceive to be the actual under-the-bonnet effects that this install had, and it may not tally with all that you know and hold dear, but I think it's fairly cocky of you to insist that I (or Twister) WON'T notice any speed increase. Because I did. So there.
ulrik
Registered
OK guys, I am using update_prebinding -verbose -root / since 10.0.0 nearly every day and I noticed a speed increase, especially in scrolling and typing after installing the Devtools 10.0.1 (and I had installed 10.0) so stop telling me that the speed gain comes from the prebinding. Startup times are improved by prebinding, but the scrolling speed and for example the genie effect have nothing to do with updated prebindings of libraries and applications, and they are definitely faster than before. Pre-Dev 10.0.1, the genie effekt on my Cube most often just played three or four frames, now it is a soft, liquid motion into the dock.
ulrik
ulrik
ezra
Super Organism
OK, I've had DevTools installed for two days now, and I too OPtimize my machine all the time. My general impression is that it does speed up your interface a bit. If you prebind your system often, it's not as noticable, but if you don't, it's much more noticable. Thanks for the tip!
ezra
Super Organism
If you installed DevTools or 10.0.4 recently it has probably already pre-binded/optimized your system. If you choose "use more mem" and don't have a lot of extra RAM, you won't see much of a speed up either. The "Use more mem" option works best for machines with 512MB of RAM and UP.
Untitled
Untitled
????
I just tried "sudo update_prebinding -verbose -root/" as an administrative User (not the root user) and I recieved a chilling message
---------
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these two things:
#1) Respect the privacy of others.
#2) Think before you type.
---------
Well, that was enough to stop me for now...
Could someone please tell me why this happened?
Did I get this message because:
#1) I was not logged on as the root user or..
#2) I have IE 5.1 installed on my computer.
It seems something like this is always built into the Mac OS (not that this is a bad thing, it's quite funny in fact.)
I have included another warning that I received many times running OS 9 in an attachment. I would also appreciate if someone could tell me why this message popped up. (I usually received the message while in AppleWorks 5.0)
I just tried "sudo update_prebinding -verbose -root/" as an administrative User (not the root user) and I recieved a chilling message
---------
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these two things:
#1) Respect the privacy of others.
#2) Think before you type.
---------
Well, that was enough to stop me for now...
Could someone please tell me why this happened?
Did I get this message because:
#1) I was not logged on as the root user or..
#2) I have IE 5.1 installed on my computer.
It seems something like this is always built into the Mac OS (not that this is a bad thing, it's quite funny in fact.)
I have included another warning that I received many times running OS 9 in an attachment. I would also appreciate if someone could tell me why this message popped up. (I usually received the message while in AppleWorks 5.0)
Attachments
vanguard
Registered
You got that message because you ran the sudo command. I get it at work sometimes too.
The idea is that you are running commands as somebody else so they give you a message as if you were invading somebody's privacy. I always think that it's a dumb message because it's contanstly falsely accusing people like you and me.
Anyway, that message is no reason to stop what you're doing.
The idea is that you are running commands as somebody else so they give you a message as if you were invading somebody's privacy. I always think that it's a dumb message because it's contanstly falsely accusing people like you and me.
Anyway, that message is no reason to stop what you're doing.
Untitled
Untitled
Thanks, that solves my concerns, now onto my next question,
There is a way to run mac os x without the GUI (graphics user interface) by typing in ">console" as the user name in the login screen.
My question is if you update the prebinding with the command "sudo update_prebinding -verbose -root/" will it "prebind faster or better" since the finder is not activated?
food for thought...
There is a way to run mac os x without the GUI (graphics user interface) by typing in ">console" as the user name in the login screen.
My question is if you update the prebinding with the command "sudo update_prebinding -verbose -root/" will it "prebind faster or better" since the finder is not activated?
food for thought...
vanguard
Registered
Having finder open (or closed) shouldn't have any effect on the results of prebinding.
In a nutshell, this is what prebinding is all about.
Most applications make calls to shared libraries. These libraries contain code for common functions. Things like accessing files, writing output to the screen, etc.
When an application starts, the OS has to make sure that all the dependent libraries are in memory. It also has to know where in the memory those libraries are.
Prebinding is a way of making a note of where those libraries are (or are going to be) so that your app doesn't have to go looking around for them as it starts up.
Installing dev tools *might* install faster versions of these libraries. I don't know. I can't see why it would update prebinding if it didn't change the libraries. That could explain the speed difference that people are seeing.
One final note, using normal observation and computer use to see if something is faster is notorious for producing lousy results. As a developer, I've sped up application operations from 30 to 15 seconds only to hear my user report, "Nope, it's still slow." I've done things that shouldn't make it any faster at all and received praise for making it faster.
The truth is, if you want to know if it's "really" faster you should have before and after times, you should test under identical conditions, and you should use a reliable timer. Everything else is subject to the operator's mood, the amount of free memory, etc.
Ok, now I'm just droning on. If anybody would like to correct a mistake in what I said (or simply comment) feel free. I'm always willing to learn.
Vanguard
In a nutshell, this is what prebinding is all about.
Most applications make calls to shared libraries. These libraries contain code for common functions. Things like accessing files, writing output to the screen, etc.
When an application starts, the OS has to make sure that all the dependent libraries are in memory. It also has to know where in the memory those libraries are.
Prebinding is a way of making a note of where those libraries are (or are going to be) so that your app doesn't have to go looking around for them as it starts up.
Installing dev tools *might* install faster versions of these libraries. I don't know. I can't see why it would update prebinding if it didn't change the libraries. That could explain the speed difference that people are seeing.
One final note, using normal observation and computer use to see if something is faster is notorious for producing lousy results. As a developer, I've sped up application operations from 30 to 15 seconds only to hear my user report, "Nope, it's still slow." I've done things that shouldn't make it any faster at all and received praise for making it faster.
The truth is, if you want to know if it's "really" faster you should have before and after times, you should test under identical conditions, and you should use a reliable timer. Everything else is subject to the operator's mood, the amount of free memory, etc.
Ok, now I'm just droning on.
If anybody would like to correct a mistake in what I said (or simply comment) feel free. I'm always willing to learn.Vanguard