This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Cygwin Filesystem Performance degradation 1.7.5 vs 1.7.7, and methods for improving performance


2010/9/29 Derry Shribman:
>> Yes, but several projects, like coreutils, are already committed to this
>> task, and since coreutils covers the most common apps you use on a daily basis,
>> it will have immediate effect.
>
> from 'committed' to actually coding the code, and then releasing it, and
> then 'cygwin ports' project updating to use it: this will takes years, and
> this is only core-utils. When will cvs, git, gnumake, apache etc use it...?
>
> Also, what about a developer with a large (slow) perl application? he will
> have to wait for perl to use and export xstat API, and then until his
> application will specifically replace stat -> xstat, and only then the
> application will work faster. This can take years.

perl core is usually fast adopting such speed improvements, esp. for File::Find.
But the typical perl use-case needs the full stat not a fast crippled xstat
as the user is free to ask for any stat field. Same as with cygwin.
With the current File::Find API we would need an opcode inspector to
check if any
extended stat field is requested in the user sub and if only not use the
faster xstat. Looks not easy to do.
Same for readdir.

The only benefit I see in coreutils and git, and those two are usually
the fastest adopters.
With perl you'll have to wait for 5.14 early next year. This will be a
bit faster, almost as
fast as 5.8.9.
-- 
Reini Urban


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]