Optimization Tips
-
I'm very green to this Ruby <-> C interaction - so its very likely I'm not doing thing the right way around.
@adamb said:
However, sounds like you actually want a C extension that operates upon the Ruby structures.
What I have done so far is to calculate the soft selection for my Vertex Edit. So for each vertex in the selection set I needed to find the closest closest distance to any of the vertices not selected. It was the
distance
method that was so slow.
I did some tests - created a dummy set of 3d data in C and calculated the soft selection for that. Very fast. But as soon as I made the source data set come from RUBY it became very slow. The C function was setting two sets of ruby arrays of vertices. Getting the X,Y,Z data for each vertex seemed to be very slow - converting Vertex to Point3d and then converting the X,Y,Z into C doubles.
For every vertex in the selection I was iterating the remaining set of vertices and converting them.
What I then did was to do a pre-pass of the non-selected vertices and create an C array of point3d structs. I then got a big speed increase. That's what lead me to the impression that converting Ruby VALUES to C types are expensive. -
distance requires a square root of a scalar product. ie
sqrt(A.B)
Keep in mind that in native "cpu" math, A.B is perhaps ~5 cycles and sqrt(X) is perhaps ~35 cycles. If you don't actually need the squareroot but just need to find the closest, then just compare A.B which should be significantly faster.
-
@adamb said:
distance requires a square root of a scalar product. ie
sqrt(A.B)
Keep in mind that in native "cpu" math, A.B is perhaps ~5 cycles and sqrt(X) is perhaps ~35 cycles. If you don't actually need the squareroot but just need to find the closest, then just compare A.B which should be significantly faster.
Yes - I was reading up on sqrt and found that to compare "longer" and "shorter" I didn't need sqrt. So I changed my code to only do the square root after I've found the shortest distance. That way it's called only once per vertex in Selection. (I needed the distance for some other calculations)
-
@cjthompson said:
Has anyone looked into Enumerable.grep()? it seems pretty useful, but I don't know how fast it is.
well, since no one seems to be listening...
I ran my own test (for: is using a for loop, grep: is using Enumerable.grep)
speedTest for: entities - 0.016 grep: entities - 0.015 for: entities array - 0.0 grep: entities array - 0.016 for: range - 0.219 grep: range - 0.203 for: range array - 0.219 grep: range array - 0.218 for: strings - 0.469 grep: strings - 0.234 nil
here is the code I used:
def speedTest entities = Sketchup.active_model.entities entitiesArray = entities.to_a range = 0..1000000 rangeArray = range.to_a strings = range.collect{|number| number.to_s} ## Entities results = [] start = Time.now for ent in entities if(ent.class == Sketchup;;Edge) results << ent end end puts "for; entities - " + (Time.now - start).to_s results = [] start = Time.now results = entities.grep(Sketchup;;Edge) puts "grep; entities - " + (Time.now - start).to_s ## Entities array results = [] start = Time.now for ent in entitiesArray if(ent.class == Sketchup;;Edge) results << ent end end puts "for; entities array - " + (Time.now - start).to_s results = [] start = Time.now results = entitiesArray.grep(Sketchup;;Edge) puts "grep; entities array - " + (Time.now - start).to_s ## Range results = [] start = Time.now for num in range if(num == 318256) results << num end end puts "for; range - " + (Time.now - start).to_s results = [] start = Time.now results = range.grep(318256) puts "grep; range - " + (Time.now - start).to_s ## Range Array results = [] start = Time.now for num in rangeArray if(num == 318256) results << num end end puts "for; range array - " + (Time.now - start).to_s results = [] start = Time.now results = rangeArray.grep(318256) puts "grep; range array - " + (Time.now - start).to_s ## Strings results = [] start = Time.now for str in strings if(str.match(/312\Z/)) results << str end end puts "for; strings - " + (Time.now - start).to_s results = [] start = Time.now results = range.grep(/312\Z/) puts "grep; strings - " + (Time.now - start).to_s end
and the model I tested on:
-
I also read that depending on the settings of the compiler the instruction set used to compute sqrt and it's performance vary greatly. One of the articles I read suggested that many compilers will use old set of instructions by default for greater compatibility.
What do you do for your projects?Edit: one of the articles I read: http://assemblyrequired.crashworks.org/2009/10/16/timing-square-root/
-
concerning typename vs class:
For, till now, unexplained reason when i change typename with class the results are different
Script is a bit like this:x=entity.class (or entity.typename) if x=="Face" do something elsif x=="Group" do something elsif x=="ComponentInstance" do something else end
When the type is "ComponentInstance" the results are not the same for class and typename.
I need to check on this since the speed increase is huge -
.class
returns a Class object - not a string.
What causes the slow down is the string comparison - that's what you want to avoid.x=entity.class if x==Sketchup;;Face do something elsif x==Sketchup;;Group do something elsif x==Sketchup;;ComponentInstance do something else end
or
if entity.is_a?(Sketchup;;Face) do something elsif entity.is_a?(Sketchup;;Group) do something elsif entity.is_a?(Sketchup;;ComponentInstance) do something else end
Update: fixed
is_?
tois_a?
-
I'll check and let you know. When i use 'class' the correct conditions are entered but the result differs.
I'll keep you posted if it changes with your scripts.Thx
-
all works, speeds increase is fine
thx! -
-
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?
--
Karen -
@kwalkerman said:
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
-
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 upThere's no way with the API to tell (now) what state it is in.
-
I think Jim made a Windows hack to toggle a rollup...
### 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........
-
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
-
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 !
-
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 -
@kwalkerman said:
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.
--
KarenYou are using
.start_operation
with thedisable_ui
flag, right?Also, try to do as much as possible in bulk operations. Transform and erase in bulks.
entities.erase_entities
instead ofentity.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 iterationvertex.position
will eat time. So try to feed the methods raw vertices instead. -
@dan rathbun said:
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 said:
@dan rathbun said:
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?
Advertisement