@thomthom said:
Also, it's correct the Ruby is slow. Very slow. Scripting languages are in nature slow because they are interpreted in real time. They cannot compete with native C code. Fortunately for Ruby one has the possibility to create Ruby C Extensions where it's possible to leverage C - which I did in Vertex Tools in order to ensure it's performance.
Whilst it may well be true that Ruby is slow, this is most decidedly not true for all languages that you might describe as 'scripting languages'. For example, it's not true that they have to be interpreted in any sense, let alone the very simplistic way implied by 'in real time'. I'm fairly experienced in implementing this stuff (like, 30 years) so forgive me if I pontificate for a few paragraphs; if this sort of thing doesn't interest you feel free to skip it.
One can implement a language as a very naive interpreter, rather like many early BASIC systems, where the actual underlying system reads the code (which might be actual text fragment by fragment and executes each bit in turn. Parsing each line every time is probably the slowest possible way to implement an language, but there may be worse things to do.
Pre-tokenising (i.e. converting the text to a list of simple flags that mean "set variable name to {next thing on stack}" or similar) saves time and simplifies the exception engine a bit.
Going a bit further actually compiles the text into sequences of simple instructions to a virtual machine that then does the real work at run time. You can do some tricks to optimise the code at this level, some of them very effective. If you define your system nicely you can make nice portable debuggers that work the same on any machine that runs the system. A very good example of this approach is Smalltalk, where one can write a program on a Mac, copy the running system across to a PC, continue running it, debug it on RISC OS, deploy it on linux and rely on it working the same everywhere. Ruby is supposed to work very similarly but to be honest I don't find the semantics and syntax anywhere near as easy to use as Smalltalk's.
A next step, that can provide dramatic performance improvements, is to take those compiled pseudo-instructions and decode them at run-time and (this is the different bit) save the decoded native machine instructions for later use. Clearly you have to be clever about how much of it you keep around taking up space, how you handle debugging (since you debug the 'real code' and not the machine code) and quite few other important details. That's why it isn't done for all systems.
Smalltalk was the first system to use this scheme starting back in '84, but it was adopted by java (spit) too when it arrived on the scene. Python is likely to get a similar system sometime and I see no special reason Ruby couldn't. The performance benefits can be dramatic.
One has to remember though that speeding up your Ruby plugins may not make much overall difference to the speed of the total work being done. If your code is driving some complex operation in SU and your code is really taking 1% of the time, then making Ruby a million times faster won't buy you anything useful.
@thomthom said:
Just a pre-emptive answer in case any one should suggest that Trimble buys plugins and convert them to native C; There is no point of buying the Ruby code - it wouldn't give anything for free to developing the C code.
Actually I think it would have a point in some cases; the design of the plugin is not just in the code. It's also in the mind(s) of the developer and includes stuff not yet working, ideas for the future, knowledge about approaches that worked and failed etc. Choosing an important plugin, contracting with the original writer and working with them to re-implement, extend or simply better support it, would be of non-trivial value.
