[ruby-core:47031] Re: [ruby-trunk - Bug #6836] Improve File.expand_path performance in Windows

On Mon, Aug 6, 2012 at 9:34 PM, U.Nakamura <[e-mail]> wrote:
>
> However, it is very difficult to write safe code because there
> are too many traps in the file system of Windows.
> It's impossible for non-Windows programmers in particular.
>
> For instance, your WEBrick patch calls Win32 API with DL,
> but Unix programmers will not know Win32 API.
>
> Therefore, we made decision of pushing all the troubles in
> File.expand_path.
>

Perhaps WEBrick patch can be changed to follow Rack approach and we
remove DL altogether.

> We expected to help to write safe code in almost all cases.
>

I understand, but also I noticed that File.expand_path is called all
over the place for things like require, loading files and ensuring
$LOAD_PATH is expanded (which was already expanded in the previous
require).

An empty Rails application generates 130K hits to File.expand_path
function, but not caused by Rails itself, but instead require uses it
internally.

That alone accounts for all the performance brief users of Windows
complain most of the time.

> Possibly this was not a good message.
> Much program depending on File.expand_path may have been made
> in the world.
> It's the reason why I am very cowardly to change the behavior
> of File.expand_path.
>
>
> But I am not against to this patch.
> I hope another people's review based on the above viewpoint.
>

I started working on this patch August 2011, almost a year ago.
Hiroshi and myself added the needed changes to make it work across
different encoding and versions of Windows.

Worth to mention this has been out in the wild since January, and we
had a successful user-base of people using it thanks to TheCodeShop
binary releases.

While I was thinking we could consider backport this to Ruby 1.9.3
(similar to improved IO), but maybe is time that Ruby 2.0 corrects
those assumptions.

Perhaps you can ask for feedback to the Japanese developers that use
Windows to test it out. I can definitely workout binary packages with
the patch applied if they don't want to compile themselves.

The more eyes into this will help us stop any remaining issue.

Once again, thank you for taking the time to look into this and much
appreciated your thoughts.
-- 
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exup駻y