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.
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.
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. |
|
This should be addressed by afb3b8b. The commit still needs further testing to ensure there are no edge cases breaking it. |
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: