All SSJS are parsed in AST (abstract syntax tree) at runtime. In other words, your code simply remains a string until it is executed, and at that moment the parser checks that String syntactically determines what the code contains: what characters denote variables that are operators, functions, etc. After this parsing is complete, the execution engine can run Java code, which is an approximation of what was developed for JavaScript code.
This is why SSJS is always slower than directly equivalent to Java: if you are just starting to write your code in Java, then it is compiled into bytecode at the time your project was created, but perhaps there’s no more need to “guess” at runtime which run the code by analyzing String ... it just runs the already defined Java code.
On the other hand, there is nothing about this process that would significantly distinguish SSJS implementation of various @Functions from native JavaScript; given that @Length (tmpStr) is just a wrapper for tmpStr.length, it doesn’t surprise me that Sven sees the difference in runtime, given the sufficient number of iterations. But if your goal is optimization, you will get much more improvement by moving all the code from SSJS blocks to bean methods than you, avoiding the convenience of @Functions in favor of native JavaScript, because even native JavaScript needs to be analyzed in AST. In this sense, there is no fundamental difference between the two.
UPDATE: There is a slight caveat to the AST analysis mentioned at the beginning of this answer. By default, the XPages runtime caches up to 400 unique SSJS expressions (you can override this restriction using the ibm.jscript.cachesize property in the xsp.properties server file). Therefore, if there is an expression that exactly matches (including a space) that is already cached, Domino does not need to create a new AST for this expression; it simply refers to a tree already in the cache. This is the MRU cache ("most recently used"), so the more often the same expression is found, the more likely it will remain in the cache. Regardless of whether the AST is cached, it still needs to be evaluated against the current context, and some of the JavaScript wrapper objects have additional overhead compared to what you are most likely to use if you just encoded directly on Java (for example, {} becomes an ObjectObject , which is similar to HashMap , but has additional functions that support closure, which are simply lost if you do not use closure anyway). But the main characteristic of this AST cache is that, unlike most development contexts, code duplication can really be good, if only in the sense that using the same exact expression again and again allows you to use everything except the first instance each skip language parsing and go straight to the challenge.