You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am running into some performance issues with larger models, and wonder about a few possible speed-up items? Specifically, I would like to propose a small change to the Honeybee Label Faces component.
Scenario:
With large models with many non-convex surfaces, this component is running very slowly for me (in the example attached, 52 surfaces takes >4 seconds for this component to run).
I have tried to do some basic profiling of the component and I think that the main item causing the slowdown appears to be the face center calculation. Specifically line #100
The pole_of_inaccessibility method appears to be the one resulting in the long run-times what I can tell?
Proposed Change:
In order to speed up the component, I would propose changing to use the built-in ghpythonlib's Area function instead (which yields the centroid) for all non-convex surfaces, and then changing that line of the component to the following:
When I tried this revised implementation on my test-model, I was able to take the Label Face component's runtime from 4.3 seconds (for 52 non-convex surfaces) to 75 ms. So something like a ~98% reduction in this case.
Do you think I'm missing any cases here which pole_of_inaccessibility handles well that Area + SurfaceClosestPoint does not? From my tests, the Area component does a pretty reliable job at finding the mid-point for most cases that I seem to have.
Example Script:
I have attached an example GH script here with some sample geometry internalized, and with the proposed changed to the component to illustrate the issue and the proposed change.
Hi @chriswmackey , @mostaphaRoudsari ,
I am running into some performance issues with larger models, and wonder about a few possible speed-up items? Specifically, I would like to propose a small change to the Honeybee Label Faces component.
Scenario:
With large models with many non-convex surfaces, this component is running very slowly for me (in the example attached, 52 surfaces takes >4 seconds for this component to run).
I have tried to do some basic profiling of the component and I think that the main item causing the slowdown appears to be the face center calculation. Specifically line #100
The
pole_of_inaccessibility
method appears to be the one resulting in the long run-times what I can tell?Proposed Change:
In order to speed up the component, I would propose changing to use the built-in
ghpythonlib
'sArea
function instead (which yields thecentroid
) for all non-convex surfaces, and then changing that line of the component to the following:When I tried this revised implementation on my test-model, I was able to take the Label Face component's runtime from 4.3 seconds (for 52 non-convex surfaces) to 75 ms. So something like a ~98% reduction in this case.
Do you think I'm missing any cases here which
pole_of_inaccessibility
handles well thatArea
+SurfaceClosestPoint
does not? From my tests, the Area component does a pretty reliable job at finding the mid-point for most cases that I seem to have.Example Script:
I have attached an example GH script here with some sample geometry internalized, and with the proposed changed to the component to illustrate the issue and the proposed change.
exampel_label_faces.gh.zip
The text was updated successfully, but these errors were encountered: