Large File Editing


This dialog box is used for configuring how CRiSP uses memory. It should not normally need to be modified but under exceptional circumstances the user may need to configure the way CRiSP works, e.g. on systems with limited swap space or RAM, or to modify CRiSP's performance characteristics, when editing large files. The default settings are more than adequate for most editing environments. As machines get more and more powerful, and memory sizes in these machines increases, there should be less need to tune these parameters. In many cases it can be difficult to measure differences in speed of operation after changing these parameters.

The options below explain the various features which allow you to tailor CRiSPs memory use behaviour. The modifiable input fields are discussed below.

Delayed file readin:  This option controls whether CRiSP will read in files in their entirety when edited, or whether CRiSP will delay read in, and read in only as necessary. The major advantage of this option is that delaying readin increases performance and startup of CRiSP, in that CRiSP does not need to read a file in its entirety before showing you the editing screen.The disadvantage of this, is that if the file is modified on disk whilst CRiSP is paging in from it, then the screen display will be erratic as CRiSP will lose synchronisation with the file. Turning off this option can improve file integrity - if two users both edit the same file, and one instance of CRiSP hasn't read in the entirety of a file, then the delayed read in will cause an error diagnostic to popup telling you that the file has changed on disk.

Source swapping    Source swapping is an option to improve memory utilisation which is useful when accessing very large files. If the other parameters in this menu cause CRiSP to use too much memory, CRiSP may discard unmodified parts of a file, and later on re-read those sections when needed (similar to Operating System paging). Source swapping enables CRiSP to re-read a section from the original source file (as opposed to writing out a section to the temporary undo file).
Source swapping not only increases memory performance but also avoids needing extra disk space to store files.
However, enabling this option can cause problems if a file is modified by another application whilst it is being edited. In this case CRiSP cannot swap back in a section of a file previously discarded. In this case CRiSP will detect the problem and pop up a dialog box telling you that the file can no longer be sensibly edited, and those sections of a file which can no longer be accessed will be displayed with question marks. Any changes you have made to the file will be available for saving since these chunks are not written out to the source file.
This option is provided for those times when you are editing huge files or files on read-only media (e.g. CD-ROM).

Tmp file swapping    This option controls whether CRiSP will maintain all parts of a file in memory, or whether to write out modified sections of a file to the temporary undo file. For large files and large editing sessions the temporary file may become very large (normally stored in /tmp but changeable by specifying a directory in the $CRTMP environment variable). If the temporary file becomes too large then you may run out of disk space in the temporary file partition.
For 99.9% of all editing operations it is safe to leave this option set either way. If you have very limited temporary storage or lots of free RAM then disable this feature.


Tuning Parameters
CRiSP stores fragments of buffers in chunks, or blocks. The Max blocks in memory attribute controls how many blocks will be kept in memory before paging will occur. Ideally this value should be set high to avoid paging. In reality, for most normal small scale editing, any value will do. If you are performing a lot of search & replace operations on large files then it can help to increase this value.

Max line length
CRiSP can handle files with lines of any length. However, extremely long lines can cause unacceptable slowdowns, e.g. when computing cursor position. If you are editing a binary file which you are not familiar with, then simply panning around the file can be a slow operation. You can use this field to specify a maximum line length and CRiSP will split lines longer than this into multiple lines on the display.

Warning: This line splitting will affect the file when you save the file. This option was added to get around problems when editing Unix files which have holes in them. This can happen for example with a log file, which appears to have been truncated, but subsequently a process continues to write to the file whilst it is still open. This can easily lead to a 200MB hole at the start of file, which CRiSP might normally treat as a single line of NULLs. By setting a line length limit, then the long lines will be split and performance should be more acceptable.

The default line length is set at 1024*1024 (1,045,876) bytes.

Lines per chunk
controls approximately how large each chunk of memory can grow to by limiting the number of lines in each chunk. A large value (say > 200) can impede performance when editing files which are colorized, as CRiSP will have more work to do. For non-colorized files, it does not make much difference to performance.
Block size    can be important as there is a fair amount of overhead needed to maintain each block. If blocks are too small then a lot of overhead will be used. If blocks are too large, then your memory usage may be too high.

Max bytes in memory
is a rough guide to how much memory will be used in all the blocks In use. The default value should be sufficient but if you have large file editing requirements and find CRiSP a little sluggish, then you could try increasing this value.
Max immediate readin size
is used to control whether a file should be read into memory or delayed until it is needed. It is primarily aimed at the Windows platform where maintaining an open file connection can cause other applications to be unable to write to the file. Any file less then this size is read into memory immediately.

Read more: Large File Editing


"We find CRiSP an excellent text editor and VITAL's support is very good."

Crisp Screenshots