14 hours to complete the 'exporting gcode' stage; what's up?

I'm having VERY slow performance during the last stage of slicing (exporting the gocde)? I just finished a slice that took 14 hours 5 minutes, and that's no exaggeration. The entire time it's stalled, slic3r is slamming the CPU. It whizzed through the stages in a few minutes, and stuck almost at the very end of the last stage (status bar approx. 90%). The STL is a bit too large to post in this thread (1.4M, but the slicing config I use is attached. I'm using slic3r v1.0RC3

I did try a different PC, with more or less the same results (I cancelled after a few hours).

If Slic3r devs are listening, I'm will to assist in any debug test you'd like me to try.

If you want to get the developers attention, you should go to the github site and post an issue. Follow the "fork me" link at the top right of the slic3r home page.

Most over time slicing can be led back to problems with the model. I have sliced thousands of models and to me a very long wait is 5 minutes. Check the file in Netfabb basic or upload it here (try to zip it to lower the file size).

I reckon if a genuine, manifold STL was sliced correctly without error in 14 hours, then the resulting g-code is probably a house

---

_______________________________________
Waitaki 3D Printer

It came out to about 46MB. It printed out pretty well until the filament ran out.. Doh.

The reason I was thinking to get dev attention is because in 1.0RC2 it sliced in about 2 hours - though admittedly not with identical settings.
I'll check out github.

I sliced a small object , 100mm X 75mm X 2.4mm and my slic3r took 2 hours to finish slicing it. I'm using newly bought Mac computer.

Quote
tru168
I sliced a small object , 100mm X 75mm X 2.4mm and my slic3r took 2 hours to finish slicing it. I'm using newly bought Mac computer.

Again probably a file with issues. If you are looking for an answer why then why not upload the file so we can look at it. BTW I use a Mac as well.

The problem is probably with 'avoid crossing perimeters'. Older algorithm does build visibility graph for layer from all vertices in layer (test all possible lines between vertices and build graph from all lines that do not cross perimeter) This is probably O(n^3) complexity (if all edges are tested in visibility test). Then dijkstra is used to find path in this graph.
New algorithm does reduce number of vertices by creating equidistant points around perimeter, so it should be much faster in complex cases.

Reducing complexity of model should help a lot - halving number of edges in layer could reduce G-code generation time eight times ..