Erik Brooks

 
Generally speaking, Lotusscript should run about 15%-40% faster on 8.0.2+ versus prior releases, primarily due to this fix:
 

SPR# BHUY75XJL2 - LotusScript is yielding too often, which was necessary a while back with slower machines. Now that Machines are much faster, we changed it to yield less often.

 
However 8.0.2 also introduced this fix:
 

SPR# DCOE6KPW48 - Fixed a crash calling fulltrim on arrays returned from certain other lotusscript builtin functions (eg Join).

 
Unfortunately this fix could cause your Lotusscript your code to run slower if you used dynamic arrays or lists. Possibly much slower - on the order of over 3-4 times as slow, even with the first fix running also.
 
During the 8.5.1 beta we noted this problem and worked with IBM. They stamped out a fix that made it into the gold 8.5.1 release. If you're not affected by the crash mentioned above (and most people won't be -- it's apparently an extreme corner case) then you can turn that fix off with this INI setting:
 

SPR# DPOL7PEHQX - The fix for SPR DCOE6KPW48 can cause a performance issue when heavy array processing is in use. This SPR provides a new ini - FullTrimFix=0 - to disable DCOE6KPW48, which then will restore performance.

 
The end result is that your script code on 8.5.1 will run significantly faster than any prior releases simply by upgrading and adding this INI setting. We're seeing around 30% in production. You may see even more. Don't forget to also do this on your servers that run script code agents.
 

I'm sure some people are jumping right in here with a raised eyebrow so let me say this up front:  I'm not tired of hearing about new features coming in 8.5.1.
 
What I'm tired of is finding and hearing about all of the things that are still broken in 8.5 FP1 that won't be fixed until 8.5.1 ships. Some of which have apparently been "fixed" since March but still didn't make it into 8.5 FP1.
 
DDE is pig-dog slow, glitchy, and buggy. And riddled with stuff that still hasn't been fixed since the 2nd Beta for 8.5.0.
 
According to some forum posts many of these things are "fixed in 8.5.1" or "much improved in 8.5.1".  Good thing we read the forum. Once again I ask: what has happened to the Fix List database? It's a ghost town.
 
8.5 shipped with enough regression bugs to sink a ship. Heck, it had a Critical Fix released the same day as it shipped. I've been working with Lotus Support on some 8.5.0 and 8.5 FP1 crashes for 2+ months revolving around the NotesViewNavigator class, which was proven buggy as far back as January. That class has been around since R5, but apparently was changed in 8.5 (for XPages, if I had to guess). Logic would dictate that IBM would have unit tested that backwards and forwards, but it obviously wasn't. This is Software Quality 101 stuff here, guys.
 
8.5.1 is supposedly on track for an October release. TEN months for a dot-one update? I think that's a new Lotus record.  Heck, 8.5's first Fix Pack was a 7-month wait. Keep in mind that there is no 8.0.3 upcoming, and there will only be minor Fix Packs to 7.0.x from here on out.
 
Perhaps 8.5.1 is so far behind the usual schedule because it's got so many wonderful new things in it. That's nice, but it's got me worried. If there are more regressions is it going to be another 7 months before 8.5.1's first Fix Pack? If this is the new Lotus release schedule, the quality better be way up there. 8.5.0 simply doesn't cut it.
 
Keep in mind that I wouldn't be so irate if it wasn't for all the good stuff that's so close, yet out-of-reach: XPages, DAOS, etc...Hopefully 8.5.1 will be the "real" 8.5.0.
 
</rant>
 

UPDATE: Here's a link to this idea on IdeaJam.

So XPages are cool.  VERY cool.  And since they can be bolted onto an existing Notes app you should be really, REALLY tempted to upgrade your existing Domino web apps with screen-by-screen updates.

Simply rewrite a form/view/etc. as an XPage and leverage all of the CSS and JSF goodness, give your users a better experience, give your app better performance, etc.  And you can finally code stuff where it's supposed to be, without having to use all of the hack-tastic legacy Domino web techniques.

But there's one big hurdle here:  XPages don't work with LotusScript.  At all.  So those legacy apps, if they use WebQueryOpen or WebQuerySave agents, are looking for a forklift-style upgrade where you get to rewrite your agents and script libraries in Javascript and/or Java.

So a cool new technology requires a massive rewrite?  Hmm.... sounds kinda like Microsoft.

But wait, it gets worse.  The Notes client doesn't support XPages (yet).  Oh, I'm sorry - did you need to use that app on the web AND in the Notes client?  Well now you get to maintain your Lotusscript libraries for the Notes client, all while maintaining new Javascript/Java libraries for XPages on the web, right?  Certainly you're ready to double your dev and testing efforts.

I know, I know - Notes 8.5.1 will get XPage support in the Notes client.  This may mean we finally have a single dev road where we can simply write an app in XPages and it Just Works(tm) in browser or client.  And that would be really, really fantastic.  But (as far as I know) Xpages still aren't going to support LotusScript.  So, again, any legacy apps will need major rewrites to take advantage of the new front-end.

I'm sure Lotus development saw this coming a mile away as a shortcoming of XPages.  It was asked about in forums for the Notes/Domino 8.5 Beta, and also the Gold release.  There's even a Wiki article that tells you how you can have an XPage run an agent (which could be an LS agent) as a pseudo-band-aid to try to help on some things.  Unfortunately that approach is riddled with shortcomings, such as requiring that you save your doc(s) prior to calling the agent (even if you're not certain you want to do so yet) and foregoing all XPage error encapsulation.  All your XPage can do is say "Hey man, I kicked off the agent, ok?"  And recreating the functionality of a WebQueryOpen agent? That's even more fun.

Naturally, I opened a PMR for this, asking to be added to the enhancement request to have XPages consume Lotusscript.  But you know what?  THERE WASN'T ONE.  Not a single SPR relating to this.

Now, certainly Lotus development has talked about this.  Certainly Design Partners have mentioned this on conference calls.  Certainly there was feedback about this in the private Betas.  I'm sure Nathan's shouted loudly that this is a huge barrier for legacy applications.  But for general customers this is the only formal means at our disposal to ask for this type of thing.

So if you too would like to see Lotusscript support in XPages, open a PMR and ask to be added to SPR# PALT7SVH29 .