Speed up

icehuli

Hi all,

I am trying to speed up my plugin. I guess the bottleneck is the drawing operations in SU. So I am thinking about using the C SDK to create and store the drawings totally in a temporary .skp model file, then import it at once to the current SU active model. Do you think it may work or not?

tt_su

@icehuli said:

I guess the bottleneck is the drawing operations in SU.

Do some benchmarking to determine for sure where the majority of the time is spent. Optimizing stuff without know it's the actual bottleneck might just waste you a lot of time, especially when the alternative you consider is using the C API.

I've had big speed improvement by learning how Ruby works. What the bottlenecks in the Ruby API is - such as creating objects and string manipulations etc.
Cache calculation and using Hash lookups can often get you there in a big way.

However, if you do a lot of calculation, then you might want to do some work in C. I made a Ruby C Extension to calculate the soft selection radius in Vertex Tools - it made for hounded of times of speed improvements.

How much gain the C API gives, I'm not sure. I've not used it yet, but I'm very curious and I have been meaning to try exactly what you propose. But I'm not sure if the overhead of writing to file and loading will give much benefit. So if you go this route I'm very curious to hear your results. But do make sure you have identified your bottlenecks. Note that the Ruby API and C API both calls the same core SketchUp functions - so it might be that it's the SketchUp core itself that's the bottleneck.

icehuli

Thanks tt_su,

I actually do a lot of calculations in the c++/c# extension. My code is kind of mixed up. I call stuff like rb_funcall, rb_num2int, rb_new_float, rb_ary_new, rb_ary_new3, rb_ary_push a lot. Yes, I will do a profiling to check my guess.

I guess that whenever something is drawn in SU, it first gets created(drawn), then SU immediately calculates the relation with other object (for example when a segment is drawn it may cut a face into two), then rendered, then the whole process again for the next entity. It is like including a "puts" routine inside Array.each, which slows down the whole thing.

tt_su

Yes, creating entities in SketchUp gets slower the more entities you already have in the collection. It's an annoying known issue.

If your profiling indicate that it's the call to the Ruby API methods that consume the most time then the only thing I can suggest that I know for sure improves performance is to use bulk methods whenever possible. For instance, when erasing multiple entities, call Entities.erase_entities instead of Entity.erase!. Same thing for transforming and modifying the selection.

Beyond that I don't know how much more you can do. It might be on us. But as I said, using SLAPI to generate geometry is something I've been very curious to try out myself. But we currently have done no performance comparisons. Ideally it shouldn't be far away from the performance we get internally.

Dan Rathbun

Thomas... what does the acronym SLAPI mean to The SketchUp Development Team ?

A search on the web shows it being used for different things.
Scalable Language API (sourceforge.net)
Software Licensing API (Microsoft)

tt_su

Sorry, the official name is "SketchUp C API". "SLAPI" was just an acronym thrown around before I begun which has stuck with me.