[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] Overhead of =dirname pathcompression logic
From: |
John Meinel |
Subject: |
Re: [Gnu-arch-users] Overhead of =dirname pathcompression logic |
Date: |
Thu, 08 Jul 2004 16:15:23 -0500 |
User-agent: |
Mozilla Thunderbird 0.7 (Windows/20040616) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Which is at least partially why =dirname needs to be cached. Because
otherwise for each path access, it has to re-open all of the =dirnames
files, and for anything new it re-writes the file. (=dirnames.new)
John
=:->
Andrew Suffield wrote:
| On Thu, Jul 08, 2004 at 03:53:59PM -0500, Ron Parker wrote:
|
|>This gives a fair idea of the current overhead resulting from
|>pathcompression versus the other Windows factors. The pathcompressed
|>get took ~21s or 59% longer than the regular tla. Additionally, as
|>John pointed out the pathcompressed get under Windows on the same
|>hardware was nearly an order of magnitude slower. Hmm, my old 300MHz
|>PII with Linux would be faster than my 2.4GHz P4 with Windows. Ouch.
|
|
| I think you'll find that it doesn't scale with processor speed. IO
| performance under windows is truly abysmal and tends to be the
| limiting factor (and NTFS is pretty bad too, which magnifies the
| effect).
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA7blrJdeBCYSNAAMRAq/mAJ9r+YKjF1hWWkdZze8G9qEdMKxm9QCgl1yh
jn9hRxvU/abyBrzYsfEMk9M=
=VmTr
-----END PGP SIGNATURE-----