Hehe grin. obviously by "hot code" i was definitely not a measure of the importance of my project, I just meant the frequency this code is running ;) funny though.
Basically the problem im solving is the same as i've been working on a long time: i am filling slices of solid objects with toolpaths. The performance issue below comes from this problem: Suppose you take a set of closed wires that compose a face. Then, the goal is to fill the face with a set of toolpaths that will fill the face. i have algos that work very fast when the infill is done with straight lines. But what i've been working on recently is to fill the face with a honeycomb pattern. to do this, i create wires that represent the top and bottom halfs of hexagons, and then lay them over the wires of the face and trim them to fit. this process requires splitting the wires ( roughly in the 'ray-trace' algo ) into sections which are inside and outside the face, and creating new wires. solving this problem, my basic test cases have 2 wires that define the face. but the hexagon fill generates something like 100 wires to cover it, and each of these wires has many edges. The snippet i submitted was part of the code to split a wire into several pieces-- to do this, it is necessary to loop over the edges in each wire. so, all that said, it turned out that looping over the wires to split them was taking a _long_ time. To give an idea, with my test case i can fill and trim straight lines to fill it in about 50 ms. but when i fill it with hexagonal wires, my initial code took 5 seconds to perform the same task. After I made a bunch of optimizations, and also the ones from this thread, i have it down to 1.2 seconds, which is still too long given that this algo must run for each z-level of a sliced solid, which could have several hundred layers. the main problem is that the code to split a wire, as well as the implementation of brepextrema_distshapeshape, appears to grow linearly with the number of edges. I guess this isnt surprising. One other approach I tried was to approximate the honeycomb wires as bsplines, so that they would be only a single edge. that worked, but execution time was longer. thanks for your interest! On Fri, Mar 4, 2011 at 2:35 AM, Jelle Feringa <jelleferi...@gmail.com>wrote: > > I just commented it out, but the 'right' solution might be to use some > > other approach to disable it. Normally log.info(...) Has trivial > > impact but this code is so hot it matters > > Well, then I get curious to know what you're up to Dave... > > > _______________________________________________ > Pythonocc-users mailing list > Pythonocc-users@gna.org > https://mail.gna.org/listinfo/pythonocc-users >
_______________________________________________ Pythonocc-users mailing list Pythonocc-users@gna.org https://mail.gna.org/listinfo/pythonocc-users
