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:

[[Image(SlicerBenchmark.png)]]

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).

[[Image(IFS_tree3_benchmark.png)]]


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.