Smalltalk's Greatest Performance Issue
The subject is an interesting discussion that took place on the VA Smalltalk mailing list. Notables:
VA Smalltalk has threaded FFI: "I have used our crypto libraries to get 6 to 7 threads of encryption streams going at once and it works great."
A GemTalk customer runs "something like 300 processes hosting a Seaside application with a Gemstone/S database." By context, "processes" here should mean OS processes.
With VA Smalltalk: "We routinely do 1-3MB image deployments on tiny IoT devices that are running full Seaside web servers and SST object remoting."
Another approach: "All my communication solutions to/from Smalltalk are done with 0MQ. 0MQ has its own working thread pool and so a large amount of CPU time is returns to Smalltalk for logic execution."
Also, two implementations of Smalltalk on .NET/DLR were mentioned. Going by their websites/repos they have not been updated for several years.
All Tags
