Add_group slow on mac

GWD

@dan rathbun said:

WoW! Excellent test report. Shows that the Mac still has a problem.

I wonder if the difference has to do with Ruby.? The Mac is still running the initial release of v1.8.5, and the PC was updated to v1.8.6-p287.

There is a thread on how to point the symbolic references for Sketchup Ruby to a "normal" full Ruby install elesewhere on the Mac's harddrive. (You need to backup the current links, so you can switch back if necessary. Perhaps a shell script?)

I'd be interested in seeing the comparison for the Mac, running v1.8.5-p0 and v1.8.6-p287, ... (and perhaps even the latest patchlevel for v1.8.7)

And here are the results for ruby 1.8.7 on mac:

100 - 0.58 sec
200 - 1.69 sec
400 - 10.55 sec
600 - 33.39 sec
1000 - 147 sec

Almost no difference with ruby 1.8.5

Dan Rathbun

Bummer... definately the problem is in the C++ code.

jhauswirth

Looking at the add_group Ruby code, its the same on both platforms.
One reason (don't know if this is true) it could be slower on the Mac
is the notifications that are sent around could be updating the Mac
UI, like the component browser. This may be more efficiently done on
the PC.

Also, the same code (duplicate code/cut-n-pasted it looks like) that
I fixed in the C++ API was also being used in the Ruby code.
The bug report only mentioned the C++ API, so that's what got fixed.

thomthom

@jhauswirth said:

Looking at the add_group Ruby code, its the same on both platforms.
One reason (don't know if this is true) it could be slower on the Mac
is the notifications that are sent around could be updating the Mac
UI, like the component browser. This may be more efficiently done on
the PC.

I have noticed that if you use Sketchup.status_text within a loop it will be very slow under OSX. It seems that the UI is forcefully freshened all the time, while on Windows you get "white-out" and the UI stops updating - but completes the loop much much faster.

But if it is the UI that slows things down, then running the test with start_operation and disable_ui argument set to true, should show a good performance increase, right?

Dan Rathbun

@John: thanks for taking a look at this, and "weighing in."

@GWD: Are all these groups to be added REALLY have all the same objects (like the example,) and just have a different location (transform) ?

GWD

@dan rathbun said:

@John: thanks for taking a look at this, and "weighing in."

@GWD: Are all these groups to be added REALLY have all the same objects (like the example,) and just have a different location (transform) ?

Dan,

No this is just a quick test that reproduce the problem. We have at this moment 2 totaly different script which have this problem.

GWD

@thomthom said:

@jhauswirth said:

Looking at the add_group Ruby code, its the same on both platforms.
One reason (don't know if this is true) it could be slower on the Mac
is the notifications that are sent around could be updating the Mac
UI, like the component browser. This may be more efficiently done on
the PC.

I have noticed that if you use Sketchup.status_text within a loop it will be very slow under OSX. It seems that the UI is forcefully freshened all the time, while on Windows you get "white-out" and the UI stops updating - but completes the loop much much faster.

But if it is the UI that slows things down, then running the test with start_operation and disable_ui argument set to true, should show a good performance increase, right?

I tested it with start_operation and it as no effect!

GWD

I just did some testing with adding components instead of groups (see script below). And the result is shokking. Placing 600 component give about the same time as the 600 groups 0.7 sec on PC and 27 sec on MAC. BUT after the script ended the MAC keep on showing the busy icon for very long time. More than 5 minutes (then i killed sketchup). I did the same test on mac with different number of components and this are the results:

50 components 0.29 sec running script 17 sec busy icon after script
100 components 0.85 sec running script 35 sec busy icon after script
200 components 3.8 sec running script 2 min 25 sec busy icon after script
300 components 7.6 sec running script more than 5 min sec busy icon after script
600 components 27 sec running script more than 5 min busy icon after script

require 'sketchup'
UI.menu("PlugIns").add_item("bugMAC Test2") {
model = Sketchup.active_model
entities = model.entities
puts '- Start test1 add_group bug on MAC -'
start = Time.now
for n in 1..600 do 
	newdef = model.definitions.add		
	newdef.name = n.to_s
	point1 = Geom;;Point3d.new(n*10,0,0)
	newdef.entities.add_cpoint point1 
	pt = Geom;;Point3d.new 0,0,0
	trans = Geom;;Transformation.new pt
	i = model.entities.add_instance(newdef, trans) 
	i.make_unique	
end
puts 'Total time; ' + (start - Time.now).to_s  
}

GWD

No solutions?

Dan Rathbun

Not surprising that it takes the same time to add groups and components, because a group is a special type of component, that also has a ComponentDefinition (whose group? attribute is true.)

The extra time, likely comes from adding all that new stuff to the Component browser. (guessing, here.)

Close any unneeded toolwindows, especially the Object browser. And use an operation with the disable_ui flag set.

That's all we can say. I guess John indicated that there were UI issues with the Mac edition. (I'm not sure if he said the SDK updates did, or did not make it into the last build... he was a bit ambiguous. But internal politics, ya know....)

You can always file a bug report. The more people that scream...

GWD

Dan, where can i post a bug report?

Dan Rathbun

@gwd said:

Dan, where can i post a bug report?

Open Sketchup... pulldown the Help menu, choose "Contact Us" ...

... your browser will open, to the Google Sketchup Contact page.

Use the "Bug Report" link, to bring up the form, and fill it out.

GWD

I submitted a bug report.

Dan Rathbun

Good news for Mac users. This issue has been reported as fixed in the 8.0M3 release.

see: SketchUp Release Notes

and get the latest MR at the SketchUp Downloads page.

th3lurker

I would have loved it if they fixed add_face too. I've found workarounds, so i don't need it now, but still.

GWD

The problem isn't fixed at all on mac. I did the test i posted before with the new version. On mac the script runs 250% slower on the new version. On pc the script runs 300% faster on the new version!

thomthom

@gwd said:

The problem isn't fixed at all on mac. I did the test i posted before with the new version. On mac the script runs 250% slower on the new version. On pc the script runs 300% faster on the new version!

Can you post your test code?

GWD

@thomthom said:

@gwd said:

The problem isn't fixed at all on mac. I did the test i posted before with the new version. On mac the script runs 250% slower on the new version. On pc the script runs 300% faster on the new version!

Can you post your test code?

You can find the code on page 3

driven

@gwd said:

You can find the code on page 3

Hi,
after a lot of digging, it appears that your test code will run in 0.8[1..3] seconds on both Snow Leopard and Mountain Lion with free or pro SU v6, v7 or v8, UNLESS you have either of these in your preference list
%(#FF00BF)[<string>OutlinerController</string>
<string>ComponentGBrowserController</string>]
these have no ill effect, but add either of the others and you beach-ball...
%(#00BF00)[<key>OpenInspectors</key>
<array>
<string>PagePanelController</string>
<string>LayerPanelController</string>
<string>StyleBrowserController</string>
<string>SoftenPanelController</string>
<string>EntityInfoController</string>
</array>]
They actually fork the main Thread into a timer loop to make the thumbnails and will do that even if the ruby has run before you open the Inspector. i.e run test code without, then zoom, orbit, make new geometry, etc... turn on 'Components' or 'Outliner' and you'll get a beach-ball.
If 'Components' is run first 'Outliner' opens straight away.

john