On Wednesday, December 9, 2020 at 10:30:54 AM UTC-5 Edward K. Ream wrote:
> Yes, and those considerations have nothing to do with teco :-) > Leo doesn't need the engineering underlying TECO - fortunately, it doesn't have to work on an architecture of segmented memory - but editing text files too large to fit in RAM needs careful design of the user interface. Here's a short description of TECO's design: The original TECO editors were created when computer systems were very memory limited, and were therefore optimized to run in small memory configurations. One way that this was accomplished was that TECO was a *pipeline editor*. Text was read from the input file into an edit buffer, and then written out to the output buffer. The only part of the file which was resident was the edit buffer, and this was typically kept quite small. Once text was paged out to the output file, it could not be called up again without writing out the entire contents of the files, and then re-reading to the point in question. <http://www.copters.com/teco.html> If that is not what you plan to deliver, you're going to need to figure out an abstraction that doesn't kill performance, and for that you're going to need to define use cases. An image editor that I support as part of my job handles multi-image files that are indexed by number. Navigation among the images in a given image editor window is a matter of indicating which image is current. This editor allows tens of thousands of images in a single file; it loads into its memory buffer as many images as will fit. As the user moves from the first image to the last, the editor swaps images between a scratch file on disk and RAM. For operations that run image-by-image from first to last, that works fairly well. It slows to a crawl on other patterns of access to images, because the engineering cannot anticipate all cases. For some of those cases, the performant solution is to provide RAM enough to hold the all the images in the desired file - or two such images, to provide for creation of a modified result. For some customers, "RAM enough" means 128 GB. The image editor does not need to load all the images from disk when opening a file, but saving a multi-image file of 32 GB of data takes time, even on a current-day workstation - the data comes from memory, or from the scratch file, it has to be written to disk, and the metadata for each image and the file as a whole have to be written as well. -- 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 leo-editor+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/ceed18fe-22b5-465f-811a-11ed8fea31b0n%40googlegroups.com.
