Optimization Tips
-
Have a look at the slideshow linked - from page 152 - it displays what does on on the C side and explains the difference. It also shows graphs for the speed difference.
The whole presentation is also interesting.
-
I did.. It is not clear.
-
@dan rathbun said:
I did.. It is not clear.
Page 154 vs 155 - you can see it does quite a lot of different things. On 154 which is the code for
attr_readerit just directly fetches the value. In page 155 you can see it invokes a whole lot more (explained partly on page 156). -
if vector1.samedirection?(vector2) => do something.... end
seams a little faster than:
next unless vector1.samedirection?(vector2) => do something...
Havent done any vigourious testing, could be specific case for me or maybe just a difference between if and unless.
Just wanted to mention I noticed some difference in speed for the 2 cases.
-
Got some numbers? I'd be surprised if there was a change due to if vs unless.
Isn't it the "do something" that makes the difference here? Because you're comparing inverted logic that control whether "do something" is executed or not...
-
We are talking ms here, but still a consistent difference for me.
I was doing the condition inside a for loop.
@unknownuser said:
Isn't it the "do something" that makes the difference here? Because you're comparing inverted logic that control whether "do something" is executed or not...
Maybe, I don't quite know the difference
This was at the end of the loop, so the loop would restart again anyway if the "if" statement was false and there where more items to process.
My theory was to shortcut whats inside the if statement and just go ahead to the next one. But that was slower..I have also noticed the same kind of ms speedgain when using if @edge VS if @edge == true while setting
true or false elsewhere in the script.
But that is probably more logic, although one could possibly expect that only if @edge needs to do more lookups.Again I could be overlooking something fundamental gotcha in Ruby, needs testing by others.
Maybe next time I'll test I 'll get opposite results
Edit: It could have something to do with that the if statement has an end in this case?
So the code get's encapsulated or something.
next unless vector1.samedirection?(vector2) => do something... end. Doesent work.Anyway it shaved 2 seconds of a process that took 30 seconds.
-
woof... just switched from using Entities.add_face to Entities.fill_from_mesh... sped up adding 100k faces significantly... Used to take over an hour, now it takes 3 minutes... ::blinks:: wow!
---- adding each face manually ----
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 45.3479998111725 sec (10k model)
inner_group.entities after import: 36232
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: ... I had to stop after waiting 35 minutes... (100k model)
inner_group.entities after import: 361832---- using add poly ----
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 2.85800004005432 sec (10k model)
inner_group.entities after import: 37348
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 209.193000078201 sec (100k model)
inner_group.entities after import: 361832---- using add point and add poly ----
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 2.79900002479553 sec (10k model)
inner_group.entities after import: 37348
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 200.332000017166 sec (100k model)
inner_group.entities after import: 361832---- using add point and add poly, passing vert and face count ----
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 3.19099998474121 sec (10k model)
inner_group.entities after import: 37348
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 182.280999898911 sec (100k model)
inner_group.entities after import: 361832---- using add point and add poly, passing vert and face count, passing arrays of floats instead of Point3d ----
inner_group.entities prior to import: 0
VfSTimer - addPreviewMeshToEntitiesObject: 179.599999904633 sec (100k model)
inner_group.entities after import: 361832 -
@whaat said:
I noticed in that thread about adding geometry to the model that someone tried creating the geometry by writing the mesh out to a temporary file format and then importing presumably with the
model.importmethod. I'll have to try this and see how it compares withfill_from_mesh. 3DS format seems like the logical choice.Would XMF or CMF files quailfy under this topic?
-
@dkendig said:
woof... just switched from using Entities.add_face to Entities.fill_from_mesh...
The reason for this is that Entities.add_face does a lot of work. It tries to merge vertices and split edges and faces. For each add_face it does a lot of comparison against all the other entities.
When you use fill_from_mesh it doesn't do this. It will try to merge points, but that is all it does. If you pre-populate the mesh with PolygonMesh.add_point first and use the indices to generate the polygons it will do even less merging and be even faster.
Entities.add_* is really best fit for Tools where you add single entities (or small set) each time. When you don't know what geometry might already be in the collection.
When you populate an empty Entities collection with a large set of entities then fill_from_mesh is the way to go. But it has some limitations that it's difficult to set properties per face and per edge.
Entities.add_faces_from_mesh is doing the same merging as Entities.add_face.
-
Thomas, this information needs to be added into the API dictionary.
-
Either that or we get the old blog up and running and link more extensive info from the docs to these longer pieces of info. Or some wiki thing. We still working on getting a better system up.
Got a long list of topics to clarify.
Advertisement