Roller is written in Ruby which is an interpreted scripting language. Thus, it is slower than Java (a bytecode-compiled language) and a lot slower than C++ (a fully compiled language). However, Ruby is very fast to develop with since it is a very high level language; this was considered a more important factor than run-time, especially since it doesn't really matter if processing takes a relatively long time.
When Roller can be run with Ruby 1.9.1, it should run significantly faster. We are also looking at code optimisations, but they are not a high priority and are unlikely to have a great effect on run-times.
The executable file, roller.exe is just a package of all the files that you need to run Roller. The files are still interpreted in the same way as when the sources are run directly.
The executable version of Roller will only run on Windows, but you can run the source version on any computer that has Ruby installed (Linux, Mac, etc).
Roller is designed as a command-line application, so that it can be run easily from batch files. A full GUI hasn't been ruled out, but it is not deemed to be necessary.
No, Roller will just use a single core, but if you want to process a lot of islands (or process a single island in a variety of ways) you can start 2 or more instances of Roller and use as many cores as you want. Remember, if you have a quad-core machine, you can always leave Roller running on one or two cores and still use your computer for most things (including playing ArmA!).
By default all objects exported by Roller are flying when imported to Visitor 3. You need to apply the v3-tools-object manager-recalculate the elevation of objects-relative displacement to 0. If you have special objects like bridges or port walls, that won't have the right position, you need to adapt their height manual in buldozer or via the Visitor 3 setAbsoluteHeight script.
Visitor 3 can only import at max 200 to 250 k objects at a time. That's why split.exe is added to Roller to be able to separate an objects file with more entries than this into multiple smaller files which can be imported one after another.
buldozer will crash with xyz data of 500 MB or more. Don't blame Roller!
Cell sizes smaller than 10m cause instability in ArmA. In addition v3 saves only one digit behind the comma. cell size 6.25 will be come 6.3 after saving. This causes some trouble when apply the SAT settings and object placement will be messed up.