Optimize This!

[Alex Tweedly]

Mark Smith wrote:

> Todd, the only problems I see are 1) that you might miss ocurrences  
> where the looked for string crosses chunk boundaries, and 2) You  
> never close the file, and as I understand it from the docs, Rev will  
> only close the file for you when the application quits.
>
> Scotts point about the size of chunk you grab is a good one, though  
> the optimal size probably depends on how much memory your  machine has.
>
> Anyway, I've done this, which is untested, but grabs larger chunks,  
> searches the chunks, (rather than starting another read) and closes  
> the file when it returns...
>
parallel evolution in action :-)    Mark and I cam up with very similar 
suggestions.

If you take the best parts of the two solutions, you'll get something 
really good

I forgot to close the file on exit (and in fact, I put in a spurious 
"close file " that will never be reached.
Mark forgot to adjust his exit criterion for the case where the string 
isn't found

> function getPositionInBinaryFile pPath,pString,pStart,pOccurrence
>   if pStart is empty then put 1 into pStart
>   if pOccurrence is empty then put 1 into pOcurrence
>   put length(pString) into strLen
>   put 100000 into tSize
>   put 0 into tFoundCount
>   put 0 into tPos
>
>    open file pPath for binary read
>
>   repeat
>     read from file pPath at pStart for tSize
>     put it into tChunk
>     if tChunk is empty then

Won't happen - the last read will be a chunk of size strLen, so you 
never exit.

>       close file pPath
>       return 0
>     end if


-- 
Alex Tweedly       http://www.tweedly.net



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.5.1/327 - Release Date: 28/04/2006