Optimization Tips

[Dan Rathbun]

One thing I have noticed is that some code runs much slower with the outliner window open. Is there a way to close the window at the start of certain code execution, and then re-open it at the end?

Maybe...
but have you tried using Model.start_operation ?

see also abort_operation and commit_operation

[Dan Rathbun]

UI.show_inspector "Outliner"
toggles it.
Shows it if it's closed
Rolls it up if it's shown
Unrolls it if it's rolled up

There's no way with the API to tell (now) what state it is in.

[TIG]

I think Jim made a Windows hack to toggle a rollup...

Code: Select all

### toggleWindows.rb - based on Jim's ideas - only for Windows...
### 20090401 TIG
### needs "win32api.so"
if [PLATFORM].grep(/mswin/)==[PLATFORM] and Sketchup.find_support_file("Win32API.so","Plugins/")
### = a Windows machine
  require 'Win32API.so'
  def toggleRollUp(name)
    findWindow = Win32API.new("user32.dll","FindWindow",['P','P'],'N')
    pw=findWindow.call(0,name)
    sendMessage = Win32API.new("user32.dll","SendMessage",['N','N','N','P'],'N')
    sendMessage.call(pw,0x00a1,2,"")#WM_NCLBUTTONDOWN
    sendMessage.call(pw,0x0202,0,"")#WM_LBUTTONUP
  end
  def isRolledUp(name)
    findWindow = Win32API.new("user32.dll","FindWindow",['P','P'],'N')
    getWindowRect= Win32API.new("user32.dll","GetWindowRect",['P','PP'],'N')
    pw=findWindow.call(0,name)
    data=Array.new.fill(0.chr,0..4*4).join
    getWindowRect.call(pw,data);
    rect=data.unpack("i*")
    #if window height is less than 90 then the window is rolledup
    return (rect[3]-rect[1])<90
  end
end#if

You add 'Outliner' to run it... test if rolled up, toggle roll up if not etc etc........

[Dan Rathbun]

its nice but...
The windows have other language names in the loacalized versions.
The code needs updating. It needs to search by ID instead.
(Or have arrays of the Inspector captions in all the local versions.)

It also should be in the SKX forum, either as a UI module extended method (which would be half done, as it's only Win32,) or a SKX::GUI::WIN method.. or something

[TIG]

I only pass on Jim's hack... if you want to 'fix' it please do... It'd be better if the API had proper access to these anyway !

[kwalkerman]

Dan, this is absolutely what I need. It is the updating of the UI that is slowing the calculation down. Having the outliner window open compounds the problem.

--
Karen

[thomthom]

Dan, this is absolutely what I need. It is the updating of the UI that is slowing the calculation down. Having the outliner window open compounds the problem.

--
Karen

You are using .start_operation with the disable_ui flag, right?

Also, try to do as much as possible in bulk operations. Transform and erase in bulks. entities.erase_entities instead of entity.erase! etc.
Cache calculation results - Ruby is horribly slow in crunching numbers.
Often, methods that accepts Point3D objects can use Vertex objects as well - though the API docs doesn't mention this. If you are doing many iteration vertex.position will eat time. So try to feed the methods raw vertices instead.

[Dan Rathbun]

its nice but...
The code needs updating. It needs to search by ID instead.
(Or have arrays of the Inspector captions in all the local versions.)

Ooops.. just checked. The Outliner does not have an ID.
But Jim's system call 'may' work. The window object can have a different "name" than the text displayed on the caption bar.
Someone running a non-English version could test it and let us know.

[Dan Rathbun]

The code needs updating. ...
(Or have arrays of the Inspector captions in all the local versions.)

But Jim's system call 'may' work. The window object can have a different "name" than the text displayed on the caption bar.

Someone running a non-English version could test it and let us know.

Didier tested it and the results are both good and bad:
see: Re: Anyone with non-english Sketchup?

[jessejames]

What I found most interesting in those test was that Vertex is a valid argument where the manual claims only Point3d. And passing the Vertex is faster than Vertex.position.

Well i think you'll find this is a commonality of the API and the Docs is the fact that "those" who are creating the API and the Docs ARE NOT "those" who use it on a daily basis!

[Jernej Vidmar]

Hi guys,

I have just found out that converting String to Length directly is up to 13x slower in comparision to converting it to Float first and only then to Length...

Code: Select all

def string_to_length_conversion(iterations=100_000)
   a=0
   t1=Time.now.to_f
   iterations.times do
      # convert to Length directly
      a = '5,0'.to_l
   end
   t2=Time.now.to_f
   puts "Conversion to Length directly took #{t2-t1} sec, a=#{a}"

   t1=Time.now.to_f
   iterations.times do
      # convert to Float, then apply units (meters in this case) and set to Length
      a = '5,0'.to_f.m.to_l
   end
   t2=Time.now.to_f
   puts "Conversion to Length via Float took #{t2-t1} sec, a=#{a}"
end
#Conversion to Length directly took 1.84500002861023 sec, a=5,00m
#Conversion to Length via Float took 0.14300012588501 sec, a=5,00m


[thomthom]

I have just found out that converting String to Length directly is up to 13x slower in comparision to converting it to Float first and only then to Length...

That is useful to know. But that assumes one has a string with only a numeral.
String.to_l will allow you to covert strings such as '20m' and '20mm'. With out any length unit indication in the string it will assume the length is in the unit of the current model.

[TIG]

BUT remember that .to_l parses any 'units' text to work out the actual value into inches...
So "1.0m".to_l >>> 39.3700787401575"
or "1'".to_l >>> 12"
BUT
"1.0m".to_f.to_l >>> 1.0"
and "1'".to_f.to_l >>> 1"
therefore you may as well miss out the second method .to_l as
"1.0m".to_f >>> 1.0
and "1'".to_f >>> 1
i.e. as a 'raw number'... AND 'raw numbers' are assumed to be in inches anyway == 1.0"...
Also .to_l and .to_f work differently if there is no 'unit' suffix...
If you have mm set as your current units then
"1".to_l >>> 0.0393700787401575 (inches)
but "1".to_f >>> 1.0 (float/number),
and with inches as the current units
"1".to_l >>> 1 (inch)
SO if you have an input that might be in anything other than inches and might have units in its string you do need to use .to_l or you risk returning a wrong value...

[Dan Rathbun]

+ vs << vs "#{}"

Benchmark Test (at ruby-talk-google)
String concatenation in ruby

[thomthom]

t=Time.now; 1000000.times{ 3**2 }; puts Time.now - t
0.948
nil

t=Time.now; 1000000.times{ 3*3 }; puts Time.now - t
0.216
nil

[thomthom]

does the whole line have to be in c? im trying to map this out---

What do you mean? Are you making a C Extension?

[thomthom]

THOM THOM WHAT KIND OF SCRIPTING LANGUAGE IS RUBY???????

Sorry, but I don't understand what 'kind' you mean. Can you elaborate a bit more?

And please, do not use all caps. It's hard to read and it's considered bad manners.

[Dan Rathbun]

Ruby is a 100% Object-Oriented Interpreted Scripting Language.

See: "Ruby Newbie's Guide to Getting Started"

[Dan Rathbun]

does the whole line have to be in c? im trying to map this out---

If you are new to Ruby... learn Ruby scripting, don't worry about it's C source code, you'll just confuse yourself. (The Ruby interpreter engine just happens to be written in C and compiled. You don't need to know C unless your involved with actually maintaining / updating the Ruby Core libraries. This has noting to do with using Ruby or writing Ruby scripts, or using Sketchup.)

[thomthom]

i += 1 vs i = i.next

i=0; t=Time.now; 10000000.times { i+=1 }; Time.now-t
2.045

i=0; t=Time.now; 10000000.times { i=i.next }; Time.now-t
1.682

[TIG]

i += 1 vs i = i.next
i=0; t=Time.now; 10000000.times { i+=1 }; Time.now-t
2.045
i=0; t=Time.now; 10000000.times { i=i.next }; Time.now-t
1.682

So avoid i='0'; t=Time.now; 10000000.times { i.next! }; Time.now-t
~8.300

[thomthom]

That would mean it's not the each loop itself that's slow - but the creation of variables.

range = (0..10000000)

t=Time.now; range.each { |i| x = i + 1 }; Time.now-t
3.402

t=Time.now; x=0; range.each { |i| x = i + 1 }; Time.now-t
2.848

t=Time.now; x=0; i=0; range.each { |i| x = i + 1 }; Time.now-t
2.39

t=Time.now; for j in range; y = j + 1; end; Time.now-t
2.196

t=Time.now; y=0; for j in range; y = j + 1; end; Time.now-t
2.186

If one has to use blocks, init the variables you use inside the block first.

[dany67300]

I have read all you optimisation tips and tried them, but nothing seems to change the speed creation of my objects. I'm using Sketchup 8 to create dominos described by a picture. To create the dominos, I tried the add_face method and the fill_from_mesh, but the times are exactly the same. It takes me about 2 s to create 400 pieces, and it's growing exponentially. With 600 pieces -> 7s, 1200 pcs -> 50s...
Is it normal to take so much time ? Each domino is created in his own group for the moment, but it doesn't change if I create them directly in my scene.

[TIG]

I have read all you optimization tips and tried them, but nothing seems to change the speed creation of my objects. I'm using Sketchup 8 to create dominoes described by a picture. To create the dominoes, I tried the add_face method and the fill_from_mesh, but the times are exactly the same. It takes me about 2 s to create 400 pieces, and it's growing exponentially. With 600 pieces -> 7s, 1200 pces -> 50s...
Is it normal to take so much time ? Each domino is created in his own group for the moment, but it doesn't change if I create them directly in my scene.

Since all dominoes are fixed by there number pattern, why not make the set as separate SKPs with common origins.
Then load them into the model when you run the script - no need to make geometry at all - and 'entities.add_instance(defn, trans)' of them as needed - the transformation used when adding determines the location and rotation.
Because they are each component instances you can swap one type for another as you wish - in code instance.definition=xxxx ...
IF you only have one simple block domino make one definition and add_instances of that multiple times... You can apply different materials separately to each instance...

[dany67300]

I hadn't seen that i could put a different material to each instance of a same defintion
thanks a lot ! it works very well

[bentleykfrog]

It takes me about 2 s to create 400 pieces, and it's growing exponentially. With 600 pieces -> 7s, 1200 pcs -> 50s...
Is it normal to take so much time ? Each domino is created in his own group for the moment, but it doesn't change if I create them directly in my scene.

I've noticed that sketchup slows down greatly once the number of groups in the current tier is greater than 1000 on my machine. Does your script speed up if the geometry is written straight to Sketchup.active_model.entities?

[thomthom]

It takes me about 2 s to create 400 pieces, and it's growing exponentially. With 600 pieces -> 7s, 1200 pcs -> 50s...
Is it normal to take so much time ? Each domino is created in his own group for the moment, but it doesn't change if I create them directly in my scene.

I've noticed that sketchup slows down greatly once the number of groups in the current tier is greater than 1000 on my machine. Does your script speed up if the geometry is written straight to Sketchup.active_model.entities?

Adding entities to SketchUp slows down in direct proportion to how many existing entities there is in the entities collection you add to.

[sm4rt]

Well I got a situation !!

C:\>ruby test.rb
range = (0..90000000)
t=Time.now; x=0; i=0; range.each { |i| x = 0b0011_1100<<2 }; Time.now-t
13.156753
t=Time.now; x=0; i=0; range.each { |i| x = 60*4 }; Time.now-t
10.400594

just a no sens !!!
Really a human oriented language

[Dan Rathbun]

The for loop should be faster, try:

t = Time.now
for i in range do
# code here
end
puts Time.now - t

[sm4rt]

Was talking about shifting binary number is longer then the same "base 10" arithmetic operation...

Which is no sense in processor calculation.
Try the same comparison in ASM, C++, PHP etc. and look the result^^

But in this case I think it's because x = 0b0011_1100<<2 affect the decimal number of the binary one to x variable so the number of edge clock needed is greater... IMO


Edit: And for loop isn't for me

Result-for-each-variables.txt

here is my results of the test that ThomThom put above to prove that for loop is better then each one and that declaring variable before is faster too but it's still not true for my equipment...
(Ruby 1.9.2-p180 / Windows 7 64 bit / Intel Core i3 M 350 2.27GHz)

So I think that these optimizations depend of many variables....(versions of Ruby/Sketchup) Even if some will still be true in the future...