In addition to what Brad said, Lucee also has features like localmode=“modern” on functions or as a global setting in the admin. There are also some options in the admin to disable the scope searching that coldfusion requires. If you are optimizing code for Lucee, you can speed it up by eliminate a lot of redundant hash map operations. Because virtually everything we write in CFML is stored in a hash map or reads a hashmap operation, this adds up to making this kind of code 2 to 5 times faster.
It’s also possible to use Lucee in a way that will make it slower then Coldfusion Standard. Because Lucee defaults to allowing each domain to run as a separate context. If you have a lot of shared library code for multiple sites, this doesn’t make sense. I redesigned my app to run all of the sites in the same context. The issue was that Lucee would have to manage separate class compilations for each domain even for code that is identical between them. You’d only have this same behavior in Coldfusion Enterprise, which allows multiple contexts. For example, my core library was around 400 cfcomponent files at that time, and I had 100 sites. Lucee had to compile and track changes on at least 400 * 100 * the number of functions java classes. I think it was tens of thousands of java classes. After I merged the sites together, it was only 400 * the number of functions, which is in the thousands, and the server can start much faster. If you are unable to redesign around this, then you might see the startup time worse, and the server requiring additional memory.
Lucee and Coldfusion are both built off servlet technology, which has concurrency scaling limits compared to non-blocking technologies, so it’s not like Lucee will serve 1000 times more request per seconds, since the underlying Java can only do so much with threads. Lucee and Coldfusion can both run out of memory a bit too easy and crash. This forces developers to split up big operations into smaller chunks because we don’t have streaming ways to work with queries in the language. I’ve started writing Java extensions to get around this limitation so we can do queries more similar to how Java JDBC works. But even JDBC is a blocking technology, so you end up needing more threads with high cpu clocks to achieve greater performance in normal Java apps. Java scales really nice to higher number of CPUs, so Lucee and Coldfusion will both be getting faster now that we have more cpus in modern systems. It’s not getting any easier to put Lucee on a tiny virtual machine. I feed the JVM many gigabtes of memory and extensively use caching and reduce hashmap operations to get the best performance.
I’ve been using Lucee since 2012 for hundreds of web sites. Using Lucee goes beyond performance really. We can affect Lucee through bug reports or code modifications since it is open source and community-oriented. I have seen that Lucee is more focused on what developers want. Lucee is as fast as you want it to be since you can build in custom Java, or at least verify it is efficient under the hood by reading the code. We can’t be sure what Coldfusion is doing under the hood. Railo & Lucee have had a good track record of making new releases that keep your code working just fine. You can also run versions of Lucee much sooner then the official release to have new features faster, and these tend to be safe to use as well.