Nikolai Weibull wrote:
> On Dec 4, 2007 5:40 PM, Tony Mechelynck <[EMAIL PROTECTED]> wrote:
>
>> skelker wrote:
>
>>> I have noticed that swap file writes are done in 4K blocks, but file
>>> reads are done in 64K blocks. If it isn't possible to adjust this
>>> behavior with configuration, then I suggest opening this up as a
>>> performance issue that could be addressed in future releases of gvim?
>
> That's not quite true, is it? The number of pages in a block times
> the page size (hopefully the page size of the file system) bytes are
> written at a time.
>
>> Swap file writes cannot be delayed, or the swap file would lose its utility:
>> thus swap file writes happen more often (sometimes much more often) than edit
>> file read/writes or swap file reads. OTOH, swap file writes are usually
>> limited to a rather small area at the end of the file. Thus it is essential
>> for performance (and also to minimize the risk of getting a power-fail
>> halfway
>> through a swap file write) to keep the swap file buffer as small as
>> reasonably
>> possible, while the "ideal" size for the edit file (which is always written
>> /in toto/, but much less often) is quite bigger.
>
> Bullshit. Unless you also fsync [1] there's no guarantee that
> anything you've written will be on disk at power-failure time. So the
> number of bytes written at a time is not relevant. In fact, writing
> fewer bytes is going to increase your chances of data loss, as you're
> making more system calls, which wastes a lot of time.
For the Vim swap files, IIUC you would be making the same number of system
calls, because IIUC whenever the CursorHold (or CursorHoldI ?) event triggers
and there has been a change since last time. Making the same number of longer
writes would increase the risk of failure.
>
> Regardless, I wonder how much of an issue this really is. It seems to
> me that the code is quite optimized
>
> [1] fsync is a slow operation, especially on a reiser4 file-system.
On a reiserfs or ext3 filesystem, it is (IIUC) less critical because of the
way the journalizing filesystem can "repair" when restarting after a failure.
And yes, in the time Vim has existed, I believe that many of the most
important optimizations have already found their way into the source code.
Best regards,
Tony.
--
As with most fine things, chocolate has its season. There is a simple
memory aid that you can use to determine whether it is the correct time
to order chocolate dishes: any month whose name contains the letter A,
E, or U is the proper time for chocolate.
-- Sandra Boynton, "Chocolate: The Consuming Passion"
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
