Die bekanntesten Slicer für RepRaps sind:

• Slic3r (Perl)
• Skeinforge (Python)
• Miracle-Grue (C++)

Ich habe mal ein paar Timing-Benchmarks mit verschiedenen Modells für alle drei Slicer gemacht:

• Bukobot Glider, 4236 Dreiecke ​http://www.thingiverse.com/thing:22268
• Bunny, 69964 Dreiecke ​http://www.thingiverse.com/thing:3731
• Eiffeltower, 139994 Dreiecke ​http://www.thingiverse.com/thing:22051
• Yoda, 198530 Dreiecke ​http://www.thingiverse.com/thing:14104

Testsetup: Ubuntu 12.04, Intel Core i5 (2.7 GHz), 6 GB DDR3 RAM. Hier die Ergebnisse:

Gemessen wurde das erzeugen von G-Code aus STL-Files, welches auch das Parsen der STL-Files beinhaltet. Um die Slicer mal auf Herz und Nieren zu überprüfen, habe ich ein Modell mit 969788 Dreiecken geslicet. ​http://www.thingiverse.com/thing:26369

Dabei gingen alle Slicer so ziemlich in die Knie (die Messwerte im folgenden Diagramm sind Minuten!). Auf meinem Laptop ist der Slic3r wegen zu hohen Speicherverbrauchs abstürzt und hat keinen G-Code produziert, deshalb habe ich den Benchmark noch mal auf meiner Workstation wiederholt (Ubuntu 12.04,AMD FX 8120 / 3.1 GHz (8 Cores), 16 GB DDR3 RAM).

Der Slic3r verbrauchte dabei mit 12.1 Gb (sic!) am meisten Speicher, gefolgt von Skeinforge mit 2.2 Gb und Miracle-Grue mit 1.6 Gb. Von Multithreading machte nur der Slic3r Gebrauch und das auch nur marginal.

Auffällig ist, das Slic3r bei diesem STL-File schneller ist als Miracle-Grue, obwohl ersterer in Perl und letzterer in C++ geschrieben ist. Augenscheinlich spielt also nicht nur die Programmiersprache, sondern auch die Komplexitätsklassen der Slicing-Algorithmen eine Rolle.