[futurebasic] Re: [FB] STR#

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : May 1999 : Group Archive : Group : All Groups

From: Jay Reeve <jktr@...>
Date: Fri, 7 May 99 23:50:04 -0500
>The suggestion that Jay made:
>FOR Myloop=1 TO itemnumber
>  POKE @DIAGNOSIS$(Myloop),48                         'Set length byte
>  BLOCKMOVE [StrHndl&]+gOffSet&,@DIAGNOSIS$(Myloop)+1,48  'move string
>  gOffSet& = gOffSet& + 48                  'get offset of next string
>really speeds the loop.  However, the READ
>FILE#FILENUMBER,@DIAGNOSIS$(0),Filesize& that I have to use still takes a
>couple of minutes over the network.  If done on a local computer, you can't
>even trace it it is so fast....therefore just a slow network.  This is still
>faster than the 30+min. that forced me to do the STR# thing.  But I still
>hate minutes instead of seconds.  


This _might_ shave another couple of ticks from the loop:

ArrayAddress& = @DIAGNOSIS$(Myloop)
DataAddress& = [StrHndl&]                    'Lock handle, just to be safe
FOR Myloop=1 TO itemnumber
  POKE ArrayAddress&,48                      'Set length byte
  BLOCKMOVE DataAddress&,ArrayAddress&+1,48  'move string
  DataAddress&  = DataAddress& + 48          'get address of next string
  ArrayAddress& = ArrayAddress& + 50         'get address of next array 

Another idea (expanding on something I suggested last night) would be to 
dispense with the loop completely and just leave your strings without 
length bytes. When you want to use one of them, copy it into a temp 
string, then copy it back into the handle where you need it:

DIM   StrHndl&
XREF@ StrHndl.48(16000)
DIM 49 tempStr$;0, lenByte;1, chars.48; padByte;1
lenByte = 48

Now you can do things like this:

chars = StrHndl(myRec)  'Now tempStr$ holds the string from record myRec
'Change or replace the data in tempStr$ however you wish
StrHndl(anotherRec) = chars   'moves data from tempStr$ into the handle

But that doesn't seem to be where your complaint is.  The classy way of 
hiding the network download time from the user would be to assign 
priorities to the data you need, and retrieve it in sections according to 
priority. The user could begin using whatever section you download first 
while lower priority data is loaded in the background.

I don't know whether you have a way of "guessing" what data your user is 
most likely to need first, but you can always adjust priority according 
to user input. I would keep an array of bit flags to indicate what has 
been loaded and what has not. If you loaded your 16,000 records in 32 
groups of 500, you could keep your bit flags in a single long integer, 
and loading 500 records would likely take seconds rather than minutes. 
Maybe 320 groups of 50 would work better. You could experiment to 
determine what size group gives you the best results.

I'm not suggesting this would be easy, but it certainly could be done, 
and would be a fairly elegant way to keep your app from suffering the 
coffee-break syndrome. I won't go into further detail unless you are 
interested in trying this approach, but you can probably figure out how 
to proceed. Ask, if you need more pointers.

 =J= a  y