Re: [Gnu-arch-users] Cygwin tla binary snapshot for Windows

[John Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ron Parker wrote:
| On Sat, 03 Jul 2004 11:14:57 -0500, John Meinel <address@hidden>
wrote:
|
|
|>First, I have to say, all of them did _much_ worse than the Linux native
|>version.
|>
|>Linux Native: 7 seconds
|>Leroy's Old Dirname (with logging): 1m24s
|>Leroy's New Dirname (no logging): 1m17s
|>Leroy's DOS (no logging): 59s
|>Ron Parker's Dirname: 1m18s
|>Johannes Port: "Never Ran"[*]
|
|
| Was the Linux test run with tla 1.2?  I believe there have been many
| optimizations done in the 1.3 code base.  Also, are you using a revlib
| on Linux?

Everything was done with tla 1.2, the officially released version. All
commands were run with tla --no-greedy-add, (I'm using a revlib under
cygwin as well).
I'm pretty sure it is similar code.

|
|
|>So I have to say, there is some significant room for improvement. All of
|>the =dirname style perform about the same. The logging doesn't take as
|>big of a penalty as I thought it would. DOS is definitely faster, though
|>not a huge amount so.
|>All of them are more than an order of magnitude slower than a native
|>TLA. Now I'm guessing cygwin imposes some overhead, as it has to
|>translate cygwin paths to NT paths, etc.
|>
|>Does anyone have an idea of how to profile this code?
|
|
| I think there is some profiling support available for Cygwin code, but
| I don't recall the details.  Beyond that I can point you to a couple
| of things that often cause code to run an order of magnitude slower
| under Windows.
|
| There first is process startup time.  Creating processes under Windows

I understand you here, except I'm pretty sure we aren't spawning a lot
of sub-processes when doing a single tla get.

|
| The other is that NTFS performance compared to any well-designed
| file-system just stinks. It's the Siamese twin of dead-dog number one.
|
| The first problem can be illustrated by ./configure'ing a package on
| Linux or BSD and doing the same on Cygwin or SFU. SFU is somewhat
| faster because MS can "cheat" and use the subsystem API's that are not
| available to Cygwin, but it is still slow.

Yeah, I'll agree with you there. ./configure is significantly slower
under Cygwin. And there is also the issue that cygwin has to translate
the unix names into Windows names. Though I know they mentioned in a
recent changelog that file system access has been improved a lot.

|
| The second can be illustrated (although still affected by the first)
| by doing a make of any large project.
|
|
|>I thought maybe pathcompress was the slowdown, but the DOS version isn't
|>~ a whole lot faster. It is a little bit faster, though, so I think doing
|>the caching will improve performance.
|
|
| Agreed.
|
Well, like I said, pathcompress caching is almost available. I need to
discuss with Lode a little bit, because my naive caching any output of
pathcompress_compress_path doesn't work. Because of how it's implemented
sometimes it will not compress anything as you supply a full path that
doesn't completely exist yet.

|
|>I'm willing to work on it with people, for right now I'm going to branch
|>of some development work from rdp's code.

Well, I managed to get your code to compile, though it is still a little
flaky for me. But all the changes I did are in my repository, the
biggest ones are in hackerlab, with a little bit of typo fixing in tar.
Also, for some reason tar's Makefile.in doesn't depend on libhackerlab.
I believe the Makefile.am does, but when I went to regenerate the
Makefile.in files, I had nothing but trouble.

Also, I added support for the environment variables
"TLA_PATHCOMPRESS_LOG", and "TLA_PATHCOMPRESS_DONT_CACHE", although
right now caching is disabled anyway because it's known to be broken.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFA6sTEJdeBCYSNAAMRAsJaAKCr7HL77UoRFHT5TYfkujViHkwiYgCgnqn7
c119jcVW/K2FUmPT4iiLptU=
=eQHs
-----END PGP SIGNATURE-----