why cura so slow?

[david-ganon 2]

i have i7 2670qm 2.2ghz

win 8.1 64 bit

8gb ram

ssd samsung 840pro

i have core temp soft, so i can see the software use

only 20% of the processors max.

why is that ?

 

[Daid 306]

Single threaded.

 

[Nicolinux 288]

Ahem, Cura isn't slow, except you have a tricky or broken model to slice. In my experience it is the fastest slicer around (single threaded as it might be).

 

[anon4321 16]

The time it takes is related to the number of facets on model has. I've seen it take 20s+ to slice a complex but valid model on a 3.1ghz I7.

Since it's single threaded, the best thing to do is throw clock cycles at it so make sure if you are using a laptop on battery that the CPU is running at max frequency.

 

[jonnybischof 60]

Make sure Intel Turbo Boost is active, and plug in the PSU of your laptop.

If you have a model that has a ridiculously high amount of polygons (100k+), well, you're going to wait...

Multi-threading would be nice, though

(10 Core i7 series coming soon )

 

[IRobertI 520]

I can tell you weren't around when Skeinforge was the main free slicer Man, those were the days. If you think cura runs slow... I think the longest I waited for a slice to complete was around 20 minutes, and then I had to change a setting and do it all over again. And if I'm not dreaming I think you even had to use a calculator for a parameter or two to get it just right. We've come a long way that's for sure.

 

[Daid 306]

I can tell you weren't around when Skeinforge was the main free slicer Man, those were the days. If you think cura runs slow... I think the longest I waited for a slice to complete was around 20 minutes, and then I had to change a setting and do it all over again. And if I'm not dreaming I think you even had to use a calculator for a parameter or two to get it just right. We've come a long way that's for sure.

I've heard people doing 18 hour slices with Skeinforge.

According to my own tests, Cura is faster then any OpenSource slicer out there right now. But that shouldn't stop us from trying to make it faster.

 

[anon4321 16]

Daid, how much "inter" layer information is required during slicing?

Slicing seems like a perfect candidate for multithreading.

In fact, over simplifying, If you have say 4 cores, if you virtually split the model up in the vertical direction into four objects, the could almost be sliced individually (in mind overly simple mind). so if the object is 20mm, you give the first thread the first 5mm, the second mm 5-10 and so on. The critical things would be to know that the part being sliced is in the middle or is the top or bottom piece and then ensuring that the gcode is adjusted so that first layer and last layer processing is done correctly, fan codes are right.

I guess the biggest problem is knowing the filament length because you need the part below the current part being sliced to be sliced to know how much filament has been fed. Or could you just zero the filament length at the start of the "sub" part? I just retraction would get screwed up doing that... or would it?

Very interesting problem.... I wish I had your job!

 

[Daid 306]

Daid, how much "inter" layer information is required during slicing?

Slicing seems like a perfect candidate for multithreading.

In fact, over simplifying, If you have say 4 cores, if you virtually split the model up in the vertical direction into four objects, the could almost be sliced individually (in mind overly simple mind). so if the object is 20mm, you give the first thread the first 5mm, the second mm 5-10 and so on. The critical things would be to know that the part being sliced is in the middle or is the top or bottom piece and then ensuring that the gcode is adjusted so that first layer and last layer processing is done correctly, fan codes are right.

I guess the biggest problem is knowing the filament length because you need the part below the current part being sliced to be sliced to know how much filament has been fed. Or could you just zero the filament length at the start of the "sub" part? I just retraction would get screwed up doing that... or would it?

Very interesting problem.... I wish I had your job!

 

You're overcomplicateing things.

There are 4 "main" steps.

1) Slice3D model into layers (no idea how to thread this, but it's very fast. It's actually the bit without progress information)

2) For each layer calculate the insets

3) For each layer calculate the top/bottom skins and sparse infill areas

4) Export each layer (calculating material amounts and so on, on the fly)

Step 2,3,4 are reporting progress information, and the process bar in Cura divides evenly on the 3 steps.

The nice thing is, for each layer in step 2 and 3, you only need information from the previous step. So a layer in step 3 only needs inset information. And a layer in step 2 only needs the sliced information from step 1.

What does this mean for multi-threading? You can turn layers into work-packages per step for step 2 and 3. For step 4 this can be done, but it's more complex, as you need to make sure you export the data in the proper order, and right now some information (final head position on the layer, final extruder and extrusion amount) is needed from the previous layer.

People have already done tests with making step 2&3 multi-threaded using OpenMP.

 

[anon4321 16]

Me? An Application Architect? Overcomplicating things? Nah...

 

[nallath 1,123]

I'm gonna stick with some good advice Daid gave me on multi threading.

1. Don't

2. No really. Don't

3. So now we've established you like hurting yourself; Keep it as simple as possible.

 

[jonnybischof 60]

To be honest, I wasn't really serious about multithreading.

Cura is super-fast, and usually I look over my settings while it slices and very often I find an error. So there's even a benefit if it takes some time to slice - it also gives you some time to breathe and look over everything again. I'm one of the people who sometimes don't "take" this time for themselves but need it "given to them" (What was it about that story with the tortoise and the hare?... ).