Yes I remember trying to slice one of the chainmail prints on crealiyprint, it took it 45 minutes, not seconds, MINUTES in total to slice the file. And then I realised that I messed up one of the settings, so guess who didn’t print chainmail on the K1 
The slice time is not that important but what could be is the amount of filament used. If the amounts quoted by the different slicers are real, maybe yes maybe no, then on a larger print it could become a real cost factor so using the slicer that uses less filament could be important. On small prints, no but on large prints there could be significant cost savings.
Has anyone actually measured the actual amount of filament used compared to the slicer quotes.
I did one a couple of years ago,
I forget exactly what values I came out with. But I remember at the time cura was slightly more accurate than everything else. All in all they were decently similar results, may be worth trying it again however to see what gets the most accuracy.
Very true I never really looked at that. I was mostly looking at print quality and print speed. I never found one to be consistently better than an other. Slice times I just measured Clocksprings torture toaster on the M1.
Prusa slicer: under one second.
Cura 4m 37s
Bambu 5m27s
It is drastically different. It is my personal issue but that absolutely infuriates me, print time I don’t stand around waiting for.
I wonder if the M1 could have any effect on it, I will try it on my ryzen based system at home tonight to see what values I get. But it is possible that Prusa may be optimized for arm whereas the other programs are not.
It is for certain running Swift code. It is optimized for Arm processors.
likely wont contribute much to this discussion but here goes;
i wasnt happy with the slice step using cura (5.4.p0) for some large, complex models, was taking WAY too long and often i just cancelled it;
was using a 12 core ryzen 9 5900x at stock settings , DDR4 at 4000
so i switched and replaced that processor with the 16 core ryzen 9 5950x, supposedly the 16 core version was 25% (note that is not far from the increase in core count) was more efficient at multicore rendering;
i use and ryzen master to monitor temps,power,usage on all cores, all at stock;
well the good news is that cura slice does indeed use all cores but that complex algorithm will make your head spin when it is described and as such might not really be that efficent; often the ‘multi-core’ processing would revert to a single core combining the results of the various multi-cores, then split loads and begin multi-core agaain, back and forth; so that slice step was using Both single and multi-core;
ok the new processor does indeed slice models that i otherwise couldnt using cura 5.4.0;
rather interesting watching the 16 cores juggle,split-and-combine the workload;
along the way my 12 core processing would on occasion thermally throttle so i upgraded to water cooling that i matched to that 16 core processor and the temps did go down and no thermal throttling at all
All 3 of them?
Hmm this is interesting,
I would be willing to bet some of the intel chips would be a good bit faster because of their P and E cores. The slicer could probably dynamically allocate tasks to both of these, so the P cores could be in charge of handling all of the algorithms while the E cores can be in charge of handling everything else. I am curious what sort of tangible benefit you get using these over AMD or Apple silicon.
This would be very challenging to demonstrate however, as there are lots of differences between all of these chips such as base and boost clocks, core count, cache, and even power consumption.
As far as I can tell just Prusaslicer is native.
Yeah from a quick google search it seems like you are correct that Prusaslicer is in fact the only arm native application.
Just ran a test on my work laptop, note it is getting pretty old and slow. Each sliced part was a benchy all with the same print settings. And I am also running an intel chip on this laptop. The time displayed below is the average over 5 runs.
PrusaSlicer - 2.35s
SuperSlicer - 2.16s
OrcaSlicer - 6.31s
Cura - 3.09s
CrealityPrint - 3.31s
BambuStudio - 4.53s
This test does start to show some of the differences in the slicers, but the model was so small I realized I needed something more complex in order to better demostrate the differences. So I decided to do this christmas tree star standing up with supports.
PrusaSlicer - 2.75s
SuperSlicer - 6.34s
OrcaSlicer - 22.5s
Cura - 59.6s
CrealityPrint - 59.52s
BambuStudio - 11.05s
And finally this castle scaled up to the max build plate size:
PrusaSlicer - 6.36s
SuperSlicer - 20.17s
OrcaSlicer - 8.13s
Cura - 13.76s
CrealityPrint - 26.77s
BambuStudio - 8.8s
So there are definitely some differences here, I am curious to do more testing and see what programs are better for what you are doing, like maybe cura is better for supports while Prusa is better for infill. Stuff like that
I have been fiddling with exactly that. I’ll be interested to see what you discover. I found so far there is no clear answer. With one model a given program produces a better print with the next model it is inferior to something else. It’s much like RAW converters in photo. Some are better at one type but not one stands best at everything.
1 Like
how about comparing the resultant g-code ? starting with sizes, if the settings in the slicers are all the same ( granted, may not be super easy ) the resultant g-code files’ sizes shouldnt vary all that much;
since those files are just ascii text then it might be possible to shake out their differences and try to interpret what they actually do and surmise why they are there;
just looking for a few seconds at that g-code it reminds me very much of programming in assembly all those years ago…
as @Matthew pointed out , my bet is the supports, those algorithms around tree supports from the buildplate have to be quite involved ( note all the sub-settings regarding supports )
1 Like
That is a great idea!
I will have to do some investigation further into this topic. If anyone else wants to take a look into this as well it is more than welcome!
Just adding my 10 cents worth here. Two weeks ago I purchased the new Creality Ender 3 v3 KE. I downloaded the latest slicer for this off Creality. I have a fairly complex stl print with numbered digits on it from 1 to 100 (A board game). I was very disappointed to see that the slicing time for this was a staggering 13 minutes and 15 seconds! What’s more is that even though there is a cancel button to stop the slicing, it doesn’t work. I have to force the program down via the taskmaster. My old slicer for my Ender 3 v3 (Creality Slicer 4.8.2) was much faster (50 times faster in fact). Here are the results of the various slicers tried:
I tried to use all the same settings in each.
Creality Print: v4.3.8.6984 13 min 15 seconds
Creality Slicer 4.8.2: 16 seconds
Orca Slicer: 24 seconds
Ultimaker Cura v5.6.0 41 seconds
Prusa 2.7.1 1 minute 28 seconds
1 Like
i have the KE , i use it exclusively with Cura ( yes deep in my heart i think prusa slicer is better and strongly suspect that orca is also better, but…)
i have had good results;
i bought the creality k1 max and used creality print and that is an inferior design and program ( i am a career IT designer ( whom all started as programmers));
get off creality print;
for cura i vaguely recall using the ender 3 v2 profile as the v3 KE wasnt yet available;
github may have some fragmented version;
Thanks for throwing your information in here!
I thought that Creality Print was an even further skinned version of Cura but it seems that it must be using a different or older version of the engine given the atrocious difference in time.
I am really looking forward to trying to figure this all out.
Matt
i found a few things in creality print unforgiveable and thus am happy to have graduated;
a couple things i still recall:
- the slicing takes two steps
–the actual print also takes 2 steps; the “time remaining” is only the first step; that 2nd step is unknown and no indication of how long that might be ( seems it was usually around 10% of the first) - the ‘history’ log overwrites based on same file names;
so for example if you print file A on monday, then tweak a few settings but dont change the file name and then print that file on Tuesday , the only record in history is of the Tuesday print, as if the monday version never happened, so you cant tell what difference your tweaks made in terms of time and filament used
1 Like