-
-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Panel optimize #169
base: master
Are you sure you want to change the base?
Panel optimize #169
Conversation
- Try to find a perfect match - If not found look for the smaller distance - Avoid using power operation for the pseudo-distance
This is a very slow process for a panel with tabs and similar stuff
# def distance(a: Point, b: Point) -> Numeric: | ||
# return math.sqrt((a[0] - b[0])**2 + (a[1] - b[1])**2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the point of commenting out this function? At the moment, it is not used. However, it makes sense to have it ready to complement pseudo_distance
. And if we want to get rid of it, we should delete it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I commented it because it isn't used, you can uncomment it when needed. Or just as a reference of what a real distance is.
I usually uncomment unused functions to avoid confusion (people might think this is used), misleading coverage results (code not covered just because is dead), avoid wasting resources, etc.
Hi! Thanks for the optimization. I have a suggestion not to use commented out code. Nevertheless, the true cost is in the following routine: Lines 429 to 469 in d2af9d4
It is cubic to the number of input segments. It could be done in n log(n). However, that would require the use of some space segmentation trees. I wanted to preserve the simplicity of the code, and I was counting on the outline being quite simple. This is, however, not the case with panels without reconstructed arcs. |
Yes, this is exactly why this patch optimizes get_closest, the bottle neck of the code you mention. |
When processing a panel with tabs and similar stuff the PCB contour is complex.
PcbDraw time needed to process these cases increases exponentially.
This patch solves a couple of issues related to extracting the PCB contour: