Are you finding @DbLookups not performing well then? Often if you do have problems it's down to view design. Generally I am happy with the @DbLookup, although I would like the limits to be extended, but there's already an idea for that: { Link }

@1: You missed the point. If a lookup in a badly designed view takes 10ms and 5ms in a beautifully designed view, both views would experience a 100% improvement if the @DBLookup function was improved by that factor.

I think the @Formula engine was rewritten couple years ago. I would assume that this particular function is pretty well optimized for speed.

I think, if a user would notice a performance gain in a lookup from 10ms to 5ms, than there is something wrong with your application. Maybee tooo many lookups?

@3: Damien Katz rewrote the whole @Formula engine in Notes 6: { Link }
I am also sure it is pretty well optimized by now.

@Mark: I never seen any performance issues using @DbLookup, if the application design have been sound. And would it be worth spending the time (both in development and in testing) to address something that is really an application design issue? Throwing resources (more memory, faster CPU, faster drives) at a problem (e.g. a slow database) is not really a good solution, it is better to fix the underlying problem (design) instead.

My understanding is that Notes is written in C which is subject to generic compiler logic. You have a class of programmers that specialise in lower level programming languages such as assembler or machine code. These guys write incredibly optimised instructions for embedded systems that are performance critical. So the same functionality, logically optmised (ie perfectly efficient logic), that compiles to 1000 instructions when written in C and then compiled into machine code, could be written in say 250 instructions if written in machine code. Get the point?

@Mark: But is that really a big problem? Yeah, perhaps IBM could put a developer on rewriting this one function slightly more optimized for you, but I am sure there are other functions who are much more important. Full round-trip DXL, for example. I never seen any performance problems using @DbLookup in a well design application. Perhaps you should spend a few hours optimizing your application design instead?

I'd rather see those retarded limits on return set size removed (or increased significantly.

LOL. Feel like promoting this idea just because it's so funny. (Sorry Mark, no offense) . I honestly thought it was a joke.

This is not a 'my lookups are better than yours' discussion. It's besides the point. An infinitely optimised sports car interior will not make the engine run more efficiently. There may actually already be certain parts of Domino that are written in lower languages than C. Anyone know?

@4: 10ms multiplied by 1000 'simultaneous' operations is 10 second response. 5 seconds if the @Lookup was twice as fast. if we have an agent doing the fabled lookup in this imaginary application and spitting out the result to a browser, the difference to the last processed request is 5 seconds. One onethosand.... Two onethousand.... Three onethousand.... Four onethosand.... Five onethousand.

Again this has nothing to do with developer prowess. A great F1 driver is limited by the performance of the vehicle.

@9: have you heard the one about the Domino to Exchange conversion utility? Command line version. :P

Point 1: Given the the complexities of manually optimizing for modern piplelined and multi-threaded chips, compounded by the fact that IBM supports many different client and server processor chips, it is highly unlikely that IBM's programmers could do a better job than the compilers that have intimate knowledge of each chip's capabilities built in.

Point 2: The performance of @DbLookup will mostly be determined by the performance of the Notes C API routines that it calls to do the database index lookups and all the NSF file i/o required for that. That code has been worked on by incredibly smart programmers for more than 20 years, and it seems highly unlikely that there are any significant performance gains to be made from code optimization. They have, on the other hand, gained performance from significant architectural updates to the ODS, caching algorithms, etc, over the years -- and those sort of things are where the achievable performance gains are likely to continue to come from.