On Wed, Dec 9, 2020 at 7:35 AM David Szent-Györgyi <[email protected]> wrote:
> > > On Saturday, October 24, 2020 at 1:07:15 PM UTC-4 Edward K. Ream wrote: > >> On Sat, Oct 24, 2020 at 11:53 AM Thomas Passin wrote: >> >>> Remembering back to long ago when we only had 640k of RAM at the most, >>> there were editors that kept three screens of data in memory at once - the >>> current page, the previous page, and the next page. When the user scrolled >>> forward (say), parts of the next page would be brought in, and when >>> necessary another page would be read in from disk. An analogy would be a >>> long continuous (paper) scroll, where only one part in the middle would be >>> visible at any one time. >>> >>> This scheme would seem to fit right in with your thoughts above. >>> >> >> Alas not. Leo's clone-find commands would pull in the entire db. That's >> why we need a search that is disconnected from positions and generators. >> > > That the clone-find commands are written to work on the entire database > does not change the engineering considerations that arise from the goal of > working on a database that is either too large to fit in RAM or is so large > that the existing code becomes too slow for a database of the desired size > even if that database does fit in RAM. > Yes, and those considerations have nothing to do with teco :-) Edward -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/CAMF8tS0%3D9nzXLKQmDQT2TJivLrgmdJ15Ny1T3sSLf3VDd4N%2BYw%40mail.gmail.com.
