4

When developing XPages applications it seems to have become very popular to mainly use Java methods and beans instead of server-side JavaScript (SSJS). SSJS of course takes longer to execute because the code has to be evaluated at runtime. However, can anyone provide information about the QUANTITATIVE gain in performance when using Java? Are there any benchmarks for how much the execution times differ, for example depending on the length of the SSJS code or the functions used?

xpages-noob
  • 1,569
  • 1
  • 10
  • 37
  • 2
    for me, the the gains of using Java as opposed to SSJS is less speed and more comfort and maintainability related. I am going to blog about this today and will post the link. – Greg Jul 18 '14 at 09:19
  • I have experience in programming Java as well as SSJS, but FOR ME coding in SSJS is much more comfortable (and much quicker). Also, I never had to face any problems with maintainability because most of my SSJS code is in libraries which I only have to copy/paste when starting a new XPages application. However, I'm really looking forward to reading your blog post in order to get more insight into your (pro-JAVA) point of view. – xpages-noob Jul 18 '14 at 10:31
  • 2
    worth reading: http://nathantfreeman.wordpress.com/2013/04/12/xpages-performance-pro-tips/ – Frantisek Kossuth Jul 18 '14 at 11:56

6 Answers6

6

You have to use your own benchmarks. The increase in time might not be measurable. It is more around capabilities and your development process. Switching from SSJS to Java an expecting an instant increase in performance most likely won't happen.

Unless of course Java allows you to code things differently. So most of the decisions are based on capabilities, not speed. You are most welcome to run some tests and share the insights. What you can expect e.g. opening a document in SSJS vs. Java: the difference should be in the space of a rounding error, since most of the time is needed for the C call below.

SSJS and Java run at almost the same speed after the SSJS has been evaluated, so you have some onramp time and similar speed thereafter.

stwissel
  • 20,110
  • 6
  • 54
  • 101
  • Thanks for your answer. It confirms my feeling/expectation that Java is not much faster than SSJS. – xpages-noob Jul 18 '14 at 10:45
  • I guess that's true if by faster you only mean the speed at which the computer runs. You're not factoring in speed of development at all it seems. – David Leedy Jul 18 '14 at 12:14
  • @DavidLeedy: From the way you phrased your comment I guess you want to say that it takes less time to develop an XPages application when using Java. After 2 years of coding SSJS and spending the last 2 months coding mostly Java in XPages, I can definitely say that I'm faster developing with SSJS than with Java. However, I wanted to keep this personal assessment out of the question because for me the only reason to favor Java over SSJS would be a (large) performance gain. – xpages-noob Jul 18 '14 at 12:47
  • That is what I'm suggesting and tried to go into more detail in my attempted answer which I admit is more "opinion" base. If you've been doing SSJS for 24 months and Java for only 2 then I'm sure you're still faster with SSJS. I was the exact same way. But now that I have a Java base for my business needs. My development is MUCH faster, higher quality, and much more reusable among different applications and even other developers on the team. – David Leedy Jul 18 '14 at 12:55
  • @DavidLeedy: That's the reason why my main question was only about code performance / execution speed. If someone has established a large code base/framework in a certain language, he probably won't feel the need to switch to another language. In my case, the need would be to improve the performance. PS: Thanks for your NotesIn9 videos. The series about "Using Java in XPages" was the main reason why I started using Java in XPages in first place. – xpages-noob Jul 18 '14 at 13:39
5

I agree about the performance gain being negligible. I will chime in to say this. Right now I am trying to learn to support an existing XPages application written without using any java, and entirely in SSJS. There is code here, there, and everywhere. It is very hard to follow.

Depending on your environment, you should consider programmer productivity when considering how to build your applications, especially when you know both. Productivity for you, and those coming after you.

Steve Zavocki
  • 1,840
  • 4
  • 21
  • 35
5

Stephan's answer is right on point: though Java as a language IS faster (you'd probably see performance gains proportional to the complexity of the block of code more than the number of operations running), the primary benefit is program structure. My experience has been that using Java extensively makes my code much cleaner, easier to debug, and MUCH easier to understand after coming back to it months later.

One of the nice side effects of this structural change does happen to be performance, but not because of anything inherent to Java: by focusing on classes and getters/setters, it makes it easier to really pay attention to expensive operations and caching. While you CAN cache your data excellently in SSJS using the various scopes, it's easier for your brain - both now and after you've forgotten what you did next year - to think about that sort of thing in Java.

Personally, even if Java executed more slowly than SSJS but the programming models in XPages were the same as they are now, I would still use Java primarily.

Jesse Gallagher
  • 4,461
  • 13
  • 11
3

You are asking about the pure processing performance - the speed of the computer running the code. And as Stephen stated Java is going to be a "little" faster because it doesn't need to do the extra step of the string parsing the code first. Ok in the big picture that's really not a big deal.

I think the real "performance" gain that you get by moving to Java in XPages is cleaner code with more capabilities. Yes you're putting a lot of code in SSJS Libraries. And that can work really well. But I assume those are more individual functions that you use over and over rather then true objects that you can put in memory and they're they're when you need them. When you get your core business logic inside Java Objects in my experience the speed of development goes significantly faster. It's not even close.

Take the Domino document object. That's a rather handy object. Imagine if it wasn't an "object" but simply a library of 50 or so functions that you need to first paste into each database. Doesn't seem right. And of course in the Domino API it's not just the domino object. There's like 60 or so different objects!

Typical XPages with Java development moves much - not all - but much of the code away from the .xsp page and into Java Classes which are very similar to custom classes on LotusScript. The not only creates separation between frontend code - making the .xsp pages easier to work with - but puts the business logic inside Java which is similar to working to the the Domino backend objects. So then the backend gets easier to work with, maintain and add onto.

And that's where a big part of the development speed improvements come from.

Getting back to your original question, which is about computer speed. I would suggest that it's much easier to cache frequently used data via Java Objects and managed beans then it is with SSJS. Not having to hit the disc as much would be a real speed advantage.

David Leedy
  • 3,583
  • 18
  • 38
  • Thanks for your answer. I have to say that only a very small portion of my SSJS code consists of individual functions. Most of the code defines classes and the corresponding prototype functions. For example, I have a class for each form in my XPages application. This allows me to easily load/save/cache/manipulate the underlying data. IMO, creating Java objects and beans, with loaders, setters, getters etc., is more or less the same thing. However, it takes ME less time to write the code for the class in SSJS than in Java (I don't have to declare variable types etc.). – xpages-noob Jul 18 '14 at 13:14
2

I would recommend you to consider performance gain in a wider context.

  • performance gain in quicker running?
  • performance gain in typing?
  • performance gain in not making mistakes because of the editor?
  • performance gain of using templating in the Java editor?
  • performance gain in better reusability, eventually to server-wide plugins?
  • performance gain in being comfortable building your own classes to hold complex objects?
  • performance gain in easier debugging?
  • performance gain in being comfortable with Validators, Converters, Phase Listeners, VariableResolvers etc?
  • performance gain in being comfortable looking at Extension Libraries to investigate or extend?
  • performance gain of being able to find answers more easily on StackOverflow or Google because you're using a standard language vs a proprietary language?
  • performance gain in using third party Java code like Apache Commons, Apache POI etc?

To be honest, when you have got that far and understand how much code is run during a page load or partial request, performance gain in runtime of Java vs SSJS is minimal compared to something like using loaded where possible instead of rendered. The gains of Java over SSJS are much wider, and I have not even mentioned the gains in professional development.

Paul Stephen Withers
  • 15,699
  • 1
  • 15
  • 33
  • Thanks for your answer. Up to now, I have only been developing rather small XPages applications and I could make everything work by using SSJS only. However, I guess in larger projects it's probably "better" to use Java for reasons like maintainability, readability etc. As @Greg pointed out: use the right tool for the right job. – xpages-noob Jul 21 '14 at 21:13
1

My answer is way too long for a stackOverflow answer, so as promised, here is a link to my blog post about this issue. Basically it has nothing to do with performance, but with Maintainability, Readability, Usability

Greg
  • 714
  • 4
  • 16