Re: Shooting myself in the foot. A classic example of taking the care upfront in the older MCD system versus the flamethrowers of today:
You have an ORDER file with a CUSTOMER CODE that points to a CUSTOMER file. You have beaucoups of dict items in the ORDER file to get at all the possible CUSTOMER info. Let's say CUST.STATE is one of them. You also have the requisite fields that are in the ORDER file like VALUE etc. Say there's 10,000 ORDERS scattered all over the USA. I would break up this single English request into 2 on the MCD: SELECT ORDER WITH CUST.STATE = "IL" AND WITH VALUE LT "100" into SELECT ORDER WITH VALUE LT "100" then SELECT ORDER WITH CUST.STATE = "IL" with perhaps an IF E # 401 thrown in between. This saves roughly 9,500 translates to the CUSTOMER file looking for "IL" and only has to find them in those with VALUE LT "100". I can't imagine anyone on this forum having to break up this sentence likewise on the current platforms. On this client's older MCD, it truly makes a difference. Am I lazy to not break this up into 2 parts on a U2 or D3 system of today? It does take a little more effort to program (and test) the 2 part method. But in the long run, the users will certainly recoup the extra cost spent today on me. Today's systems seem to cover a lot of programming ineffeciencies, albeit unintentional. A separate question. Are anyone's query processor capable of breaking up an ANDed request and not try test #2 if test #1 fails. Just wondering. My 1 cent. ----- Original Message ----- From: "Chuck Mongiovi" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, November 08, 2004 9:18 AM Subject: RE: [U2] PICK Assembler Language > > Ok, so I'm a geek. What can I say? :) > > And for all of the rest of the geeks out there, try this links out: > > http://www.256b.com/ > > There was another link out there about making the smalles possible LINUX > executable - comparing the size of one generated with a C-compiler vs an > NASM compiler vs building it by hand to be the smallest, but I can't find it > .. > > > 230 simultaneous serial users plus 22 serial printers on a 75Mhz 486. > > > Funny how earlier the effort was borne on the programmer to be as > efficient > > as he could to make up for the deficiencies of the platform. Now-a-days, > the > > processors are so infinitely fast that they clearly cover up less > efficient > > programming. > > > Therefore, it's easy to forget how far we've come. > > You know, I was about to cheer your efficiency argument - since I *still* > try to be as efficient as possible regardless of the platform that I'm on, > but then you went and shot yourself in the foot ;) > > The server I'm working on is IMHO *very* fast, but we run on SB+, which > makes it extremely easy to do tons of extra reads than are actually > necessary .. I've also got a few programmers who don't quite understand the > downside and performance implications of large DYNAMIC arrays .. > > Ce la vie .. > ------- > u2-users mailing list > [EMAIL PROTECTED] > To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [EMAIL PROTECTED] To unsubscribe please visit http://listserver.u2ug.org/
