Talk:How-To Improve Large String Performance Using Buffers: Difference between revisions

From Pickwiki
Jump to navigationJump to search
IanMcGowan (talk | contribs)
Created page with "If the final destination for the data (BUFFER in this example) is a file, I tend to use WRITESEQ APPEND to directly send the data there. In my application it would be unusual..."
 
IanMcGowan (talk | contribs)
Add nowiki
 
Line 3: Line 3:
The opposite problem is having a large string that you need to process. I convert any delimiters to @AM or @VM, then use the REMOVE trick to make stepping through the string orders of magnitude faster.  E.g.
The opposite problem is having a large string that you need to process. I convert any delimiters to @AM or @VM, then use the REMOVE trick to make stepping through the string orders of magnitude faster.  E.g.


READ BUFFER FROM ..
<nowiki>READ BUFFER FROM ..
LOOP
LOOP
   REMOVE NEXT.VAL FROM BUFFER SETTING MORE
   REMOVE NEXT.VAL FROM BUFFER SETTING MORE
Line 9: Line 9:
   GOSUB PROCESS.NEXT.VAL
   GOSUB PROCESS.NEXT.VAL
REPEAT
REPEAT
</nowiki>


instead of
instead of


READ BUFFER FROM ..
<nowiki>READ BUFFER FROM ..
MAX=DCOUNT(BUFFER,@AM)
MAX=DCOUNT(BUFFER,@AM)
FOR I=1 TO MAX
FOR I=1 TO MAX
Line 18: Line 19:
   GOSUB PROCESS.NEXT.VAL
   GOSUB PROCESS.NEXT.VAL
NEXT I
NEXT I
</nowiki>

Latest revision as of 17:30, 1 October 2020

If the final destination for the data (BUFFER in this example) is a file, I tend to use WRITESEQ APPEND to directly send the data there. In my application it would be unusual to store a 12MB record in a hashed file..

The opposite problem is having a large string that you need to process. I convert any delimiters to @AM or @VM, then use the REMOVE trick to make stepping through the string orders of magnitude faster. E.g.

READ BUFFER FROM ..
LOOP
  REMOVE NEXT.VAL FROM BUFFER SETTING MORE
WHILE MORE DO
  GOSUB PROCESS.NEXT.VAL
REPEAT

instead of

READ BUFFER FROM ..
MAX=DCOUNT(BUFFER,@AM)
FOR I=1 TO MAX
  NEXT.VAL=BUFFER<I>
  GOSUB PROCESS.NEXT.VAL
NEXT I