The trim is very time consuming in large model

Developers Ruby API
1

The more models there (Sketchup.active_model.entities) are, the more time it takes to interleave the two models (g1.trim(g2)).

When there are two groups in the model, This method g1.trim(g2) takes 0.1s.
When there are two thousand groups, This method g1.trim(g2) takes 100s.

The (g1、g2) is always the same two groups, only the total amount of models in the model is different

2

When SKP model files are imported into SketchUp they become components, not “models in models”.

Have you tried putting the 2 groups into a temporary group alone then doing the trim ?

3

Yes, I am. And The add_group is slow in the large model. The consumption time is proportional to the number of models.

4

In the groups themselves ? … or outside the temporary group ?

5 
g = Sketchup.active_model.entities.grep(Sketchup::Group)[0]
group = Sketchup.active_model.entities.grep(Sketchup::Group)[1]

g1 = g.entities.grep(Sketchup::Group)[0]
tr = group.transformation * g.transformation
# add group to g
g2 = g.entities.add_instance(group.definition,tr)
g1.trim(g2)
6

Okay … I suppose the answer is that g is the temporary group and the trim is being done within it.

Now … do the number of entities within the definitions for both g1 and g2 remain the same as the outside model gets larger ?

… or are you seeing the time increase when the outer model gets larger and both g1 and g2 remain the same ?

7

That’s interesting…

Can you log an issue in the issue tracker, providing example models and code please?
Issues · SketchUp/api-issue-tracker (github.com)

8

@tt_su @DanRathbun Test model

# small
g1 = Sketchup.active_model.entities.find { |ent|
  ent.is_a?(Sketchup::Group) && ent&.material&.name == 'Marc_Wrist'
}

g2 = Sketchup.active_model.entities.find { |ent|
  ent.is_a?(Sketchup::Group) && ent&.material&.name == 'Marc_Shoes3'
}

g3 = Sketchup.active_model.entities.find { |ent|
  ent.is_a?(Sketchup::Group) && ent&.material&.name == 'Marc_Hair'
}
s = Time.now
g1.trim g2
puts Time.now - s  # 0.022106s
Sketchup.undo

# large
g1 = Sketchup.active_model.entities.find { |ent|
  ent.is_a?(Sketchup::Group) && ent&.material&.name == 'Marc_Wrist'
}

g2 = Sketchup.active_model.entities.find { |ent|
  ent.is_a?(Sketchup::Group) && ent&.material&.name == 'Marc_Shoes3'
}

g3 = Sketchup.active_model.entities.find { |ent|
  ent.is_a?(Sketchup::Group) && ent&.material&.name == 'Marc_Hair'
}
Sketchup.active_model.start_operation 'copy_make_g3',true
1000.times do |i|
  tr = Geom::Transformation.new(Geom::Point3d.new(0,10*(i+1),0))
  g4 = g3.copy
  g4 = g4.make_unique
  g4.transform!(tr)
end
Sketchup.active_model.commit_operation

s = Time.now
g1.trim g2
puts "large : #{Time.now - s}"  # large : 0.202183

Sketchup.undo

trim_test_model.skp (114.7 KB)

9

I see similar effect on my machine:

0.0083596
large : 0.222494

We have to run this through the profiler to get an idea of what’s going on. I’m not sure I can do that right away, these things tend to eat time. But I’m logging an issue to look into it.

1 Like
10

Thank you.

11

It looks to relate to the groups being trimmed being made unique, whereupon SU it looking for a new unique name. When you have a lot of other groups in the model a lot of the definitions start with “Group” and it has to traverse for longer to find a unique name. Logged as an performance issue.

2 Likes
12

By the way, the function (add_group) has the same problem.
This means that I can avoid the problem by changing the name (no start with “Group”).

13

Yea, it also tries to find a unique name.

That might work… worth a try.