[Lazarus] filesystem timing Linux vs Win

[Sven Barth]

On 27.11.2010 21:00, Florian Klämpfl wrote:
> Am 27.11.2010 20:31, schrieb Mattias Gaertner:
>> On Sat, 27 Nov 2010 20:14:38 +0100
>> Florian Klämpfl<florian at freepascal.org>  wrote:
>>
>>> Am 27.11.2010 18:53, schrieb Henry Vermaak:
>>>> Also, the features of the filesystems
>>>> are so different, you can't even compare them.  fat and ntfs are stuck
>>>> in the dark ages compared to ext*.
>>>
>>> Modern NTFS implementations have some really nice and advanced features
>>> none of the ext* has: snapshoting (saves file server admins a lot of
>>> time :)) and transactions. I guess especially snapshotting makes ntfs
>>> slow: CoW semantics simply requires a lot of coping of files and
>>> fragments probably the disc. I made a similiar experience with btrfs
>>> (whsich has CoW semantics by default as well) on linux, working with fpc
>>> on a btrfs partition made fpc really slow. I didn't test further by
>>> turning off CoW for btrfs, but it might be reason.
>>
>> Florian, the reading/writing of files seems to be ok under Windows. But
>> the file access functions are much slower than under Linux (file exists,
>> date, open, close).
>> fpc already caches these attributes, but of course it has to read them
>> every time it starts. It reads over 80 directories. Maybe
>> someone can check how much time this costs under windows.
>
> I checked these things some years ago but at this time this wasn't a
> problem. As Sven already mentioned, the only real bottleneck on windows
> is process startup time.
>

Hmm... it might be interesting to compile FPC for pure Native NT. Then 
we could test what the Win32 subsystem adds to the startup time :D

[OT]Can I cross compile FPC for another target using the Makefile? Does 
FPC use units (outside of compiler) that aren't part of the RTL?[/OT]

> Besides turning off atime, another important things on windows are:
> never ever fill a hard disk more than approx. 80%. Filling a partition
> more than 87.5% will probably fragment the MFT and this makes a system
> really slow.
>
> But after the first compilation, this is void anyways, all files are in
> the disk cache if the system has sufficient memory.
>

Except when you send the system to standby or hibernation... then you 
sometimes need to wait longer then after a cold start until the compiler 
starts compiling ^^ (because the disk cache is empty again?)

>>
>> BTW, some file systems like zfs under Linux have snapshots too,
>> and the file access is still as fast as ext*.
>
> Of course, it might depend on the FS where it has its weakness: recently
> I unpacked gcc sources on an xfs partition: it took several minutes, on
> ext3 this takes only a few seconds.

Wow O.o I should test something like this on my computer... (ext4, xfs 
and ntfs)

Regards,
Sven