If your table is large you may benefit by setting a page reference pattern to have the table pages prefetched for you. This only applies to 31-bit storage.
You can add a prefetch data instruction to the table scan 'get next row' logic to give a hint to the CPU about what data you will be referencing next and it can preload the data into the cache before you reference it. These two suggestions can improve your loop performance if you are doing a serial scan against a large table. Jeff > On Jun 20, 2017, at 4:46 PM, Charles Mills <charl...@mcn.org> wrote: > > I have been out of the office and half-following this thread on my phone. If > it were I, I think I would do the most straightforward thing: > > LOOP EQU * > CLI MASK.FIELD1,'*' > JE Wild1 > CLC MASK.FIELD1,TABLE.FIELD1 > JNE LOOPX > Wild1 EQU * > CLI MASK.FIELD2,'*' > Etc. > J Found > LOOPX EQU * > * Bump to next table entry > J LOOP > > Do the field most likely to be unequal first, then the second most likely, > and so forth. If the first field is unequal 90% of the time then you have a > pretty tight loop: CLI/JE/CLC/JNE/Bump. > > And if I had a performance problem, only then would I attempt to address it. > > Charles > > > -----Original Message----- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Tony Harminc > Sent: Tuesday, June 20, 2017 11:10 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Table Searchig with a Mask > >> On 20 June 2017 at 12:13, Gary Weinhold <weinh...@dkl.com> wrote: >> >> >> But since the "*"s to indicate a wild card are at fixed locations in >> the table, a CLI should be better performance than TR or TRT. > > > And depending on the numbers of Structure and Array entries, and the number > of *'d elements, it may well make sense to perform the single-instruction > compare (CLC?) first, and look at the *s only if that compare fails. It's > pretty much impossible to choose the right algorithm in the absence of the > numbers of these various items. > > Tony H.
