Ruby performance on a Mac... am I just late to the party?

thomthom

@dan rathbun said:

Might the diff be your Mac is running Ruby 1.8.5 initial release (2006-08-25), and the PC edition is running 1.8.6-p287 (which I notice is nearing 2.5 years old.) ??

But wouldn't you then get a speed difference in SU on Windows prior to SU8? Which was running 1.8.0? It's a difference of 100 times, something has to be wrong.

Dan Rathbun

Well run the same tests on 7.x under Ruby 1.8.0 and we'll have numbers to talk about.

I haven't seen the test code.. so I don't know what to look for in the Ruby ChangeLogs.

thomthom

@dan rathbun said:

I haven't seen the test code.. so I don't know what to look for in the Ruby ChangeLogs.

Basically iterates the selection and for each edge: edge.find_faces

Dan Rathbun

Well there is the diff of Objective-C on the Mac, and C++ on Windows.

And as we proved for .. in seems to run twice as fast as each.. but it's a platform difference.

Hmmm... may be that sometime after 1.8.5 (initial) they may have increased the default Ruby starting stack size. (I seem to remember something about that.)

But.. I also thot in other tests, people were saying that Macs ran faster. They are always calling the PC opsys "WinDOSE".

jeff hammond

@dan rathbun said:

You Mac guys need to find a way to get a newer Ruby Framework installed under Sketchup.

i've tried a few things (putting an alias in place of the sketchup ruby.. copying the entire Ruby.framework from os x in place of sketchup.app's Ruby.framework, plus a couple of other things)

sketchup won't launch..

fwiw, sketchup's ruby.frameworks is ~1MB in size where as the osx ruby.frameworks is over 200MB..

i don't mind poking around and experimenting with stuff but since we're dealing with the system library here, i'd rather not poke too much without having a clue about these things ..

i would think that google would have tied into the system ruby if it were as easy as something i'd be able to do.. there must be something else going on.. i mean, a lot of the su team seem to be mac users and i can't imagine why they'd keep an outdated version of ruby in there without some sort of reasoning?

thomthom

@dan rathbun said:

And as we proved for .. in seems to run twice as fast as each.. but it's a platform difference.

?
Platform difference?

for .. in runs faster because it doesn't create a new local scope and new variables. .each creates new objects for each iteration, which is more expensive.

thomthom

Just ran makefaces on my MacMini OSX 10.5

There were 954 selected items.

There were 0 non-Edge selected items.
There were 954 Edges selected.

There were 451 face(s) added.
The process lasted: 2.175241 Second(s).`

thomthom

With pb.update

There were 954 selected items.

There were 0 non-Edge selected items.
There were 954 Edges selected.

There were 451 face(s) added.
The process lasted: 2.502378 Second(s).`

Without pb.update

There were 954 selected items.

There were 0 non-Edge selected items.
There were 954 Edges selected.

There were 451 face(s) added.
The process lasted: 0.433242 Second(s).`

So the lag is due to something in Progressbar.update

jeff hammond

fwiw, i remember when chrisF was making shapebender.. it was super fast at first but then he added progress bar to it and it slowed to a crawl.. i mentioned it to him but i don't think he believed me

thomthom

It all boils down to Sketchup.set_status_text or Sketchup.status_text=. Remove them and the script runs fast.

It seems that OSX always updates the UI even when plugins do heavy processing. As oppose to Windows where the UI stops responding.

So I am guessing the lags comes from that and one should avoid updating the statusbar too often.

thomthom

t=Time.now; 1000.times { |i| Sketchup.status_text = "Foo #{i}" }; puts Time.now - t

OSX: 2.08987 (You see the statusbar update for each iteration.)
Windows: 0.114 (You do see the statusbar update, but the text is a blur as it's much faster.)

Conclusion: Sketchup.status_text= has very poor performance under OSX!

jeff hammond

hmm.. makes me wonder if those two lines are affecting performance of other plugins i have..

here's a list of all the rubies i have which include those lines..

(search term shown in top-right of finder window)

screen 2011-01-30 at 1.39.57 PM.jpg

that said, the only one of those listed rubies that i think could be sped up would be jointPushPull (and shapebender as i mentioned earlier).. if i run it on a more complex surface, it takes a while to complete but i just figured that's how it was.. maybe it's speed-upable on mac?

(not saying that the others aren't affected.. it's just that i use JPP a lot and/or i'm feeding it more complex tasks where as the others that i use are more simple)

thomthom

@unknownuser said:

hmm.. makes me wonder if those two lines are affecting performance of other plugins i have..

It's a good possibility if they call these methods from within loops.
I will have to profile some of my plugins under OSX.

Dan Rathbun

@thomthom said:

@dan rathbun said:

And as we proved for .. in seems to run twice as fast as each.. but it's a platform difference.

Platform difference?

Sorry ... confusing run-on sentence. The second part was refering to the issue at hand, not the first part of the sentence. (I was tired, and my fingers were not keeping up with my brain. I should have made the last part a full sentence with a proper object.)

Anyway.. you've found the culprit. We already know Ruby string handling can be slow.

I would also suggest (I discussed this in another topic,) that when ever you need to send text to the statusbar, that you use a single quoted string for as much of it as possible with the string append operator << to add replacable portions.

Sketchup.set_status_text("Please wait. Generating face #{face_num} of #{total} faces.")
causes Ruby to parse the entire string for regular expressions, special characters ("\n",) and replacable parameters.
I would use:
Sketchup.set_status_text('Please wait. Generating face '<<"#{face_num.to_s} of #{total.to_s}"<<' faces.')
or:
Sketchup.set_status_text('Please wait. Generating face '<<face_num.to_s<<' of '<<total.to_s'<<' faces.')
But NOT this:
Sketchup.set_status_text('Please wait. Generating face '+face_num.to_s+' of '+total.to_s+' faces.')
as the latter causes Ruby to create 9 string objects, and the former only 5.

Another issue is needlessly updating the statusbar. If the resolution of a progressbar is say 20 '|' characters, then only update the progressbar on each 5% 'milestone' of the job completion (not every iteration.)

The last issue (if OSX redraws the UI very often,) is to streamline UI object (menuitem and toolbar command,) validation procs. See the other topic: [code] Menu Validation (MF_DISABLED bugged on PC?)

thomthom

@dan rathbun said:

I would also suggest (I discussed this in another topic,) that when ever you need to send text to the statusbar, that you use a single quoted string for as much of it as possible with the string append operator << to add replacable portions.

Sketchup.set_status_text("Please wait. Generating face #{face_num} of #{total} faces.")
causes Ruby to parse the entire string for regular expressions, special characters ("\n",) and replacable parameters.
I would use:
Sketchup.set_status_text('Please wait. Generating face '<<"#{face_num.to_s} of #{total.to_s}"<<' faces.')
or:
Sketchup.set_status_text('Please wait. Generating face '<<face_num.to_s<<' of '<<total.to_s'<<' faces.')
But NOT this:
Sketchup.set_status_text('Please wait. Generating face '+face_num.to_s+' of '+total.to_s+' faces.')
as the latter causes Ruby to create 9 string objects, and the former only 5.

I think I read somewhere (was it The Ruby Programming Language? - and other places) that "string #{variable}" is the recommended way to generate strings with variables. The extra processing with double quotes was negligible. (Though I always use single quotes as default - remains of my PHP days.)
` > cls
t=Time.now; total=100000; total.times { |i| x = "Please wait. Generating face #{i} of #{total} faces." }; puts Time.now-t
0.22

t=Time.now; total=100000; total.times { |i| x = 'Please wait. Generating face '<<"#{i.to_s} of #{total.to_s}"<<' faces.' }; puts Time.now-t
0.393

t=Time.now; total=10000; total.times { |i| x = 'Please wait. Generating face '<<i.to_s<<' of '<<total.to_s<<' faces.' }; puts Time.now-t
0.029

t=Time.now; total=10000; total.times { |i| x = 'Please wait. Generating face '+i.to_s+' of '+total.to_s+' faces.' }; puts Time.now-t
0.024`

@dan rathbun said:

nother issue is needlessly updating the statusbar. If the resolution of a progressbar is say 20 '|' characters, then only update the progressbar on each 5% 'milestone' of the job completion (not every iteration.)

This is where the main issue is at the moment when it comes to updating the statusbar. The generation of the strings are nothing compared.

thomthom

Some more test data:

http://www.igvita.com/2008/07/08/6-optimization-tips-for-ruby-mri/
(The link to Chris Blackburn's site it links to is dead. But there's an archived version: http://replay.waybackmachine.org/20090212130913/http://blog.cbciweb.com/2008/06/10/ruby-performance-use-double-quotes-vs-single-quotes )
Interesting comment on this article: http://replay.waybackmachine.org/20090212130913/http://blog.cbciweb.com/2008/06/10/ruby-performance-use-double-quotes-vs-single-quotes#comment-49

http://blog.purepistos.net/index.php/2008/07/14/benchmarking-ruby-string-interpolation-concatenation-and-appending/

One thing that these test doesn't always mention is what Ruby version they where run on. That might make a difference. So the only reliable results is to try out in SketchUp.

todd burch

Ah! This is great. I had no idea. When I wrote progressbar, I could not spell Mac. And since I've moved to the Mac - I have never re-profiled. I will adjust the logic in progressbar to be a better citizen on the Mac.

I would have liked to have responded sooner, but I worked all weekend 'til the wee hours. Thank you all for your input and analysis. I would not have guessed it was the status bar updates. I have commented on the Ruby API doc.

Todd

thomthom

@unknownuser said:

Ah! This is great. I had no idea. When I wrote progressbar, I could not spell Mac. And since I've moved to the Mac - I have never re-profiled. I will adjust the logic in progressbar to be a better citizen on the Mac.

I'd not have thought of checking this had you not made this post. I had made my own progress wrapper right before you posted. It ensures that the statusbar doesn't update more often than a given time, atm 0.1s. I need to check if this is still too quick.

@unknownuser said:

I have commented on the Ruby API doc.

Good thinking.
I've reported the issue to Google. The lag we see under OSX seems unreasonable.

todd burch

See my first post - I already reported.