From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: testing for a remote file to include file on a Windows mapped drive Date: Tue, 22 Apr 2008 02:27:40 -0400 Message-ID: References: <87bq781bf7.fsf@gmx.de> <000a01c8a314$5fff7630$0200a8c0@us.oracle.com> <000d01c8a324$97820590$0200a8c0@us.oracle.com> <000f01c8a334$b2a40660$0200a8c0@us.oracle.com> <000101c8a37f$eeb543d0$0200a8c0@us.oracle.com> <480C4220.3030100@gnu.org> <000701c8a383$e545a890$0200a8c0@us.oracle.com> <00af01c8a3fc$b2bac5d0$c2b22382@us.oracle.com> <004e01c8a433$680933a0$0200a8c0@us.oracle.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1208850849 12070 80.91.229.12 (22 Apr 2008 07:54:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Apr 2008 07:54:09 +0000 (UTC) Cc: emacs-devel@gnu.org, michael.albinus@gmx.de, monnier@iro.umontreal.ca, jasonr@gnu.org To: "Drew Adams" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 22 09:54:43 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JoDKp-0007hy-Ib for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2008 09:54:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoDK9-0001Pq-Nv for ged-emacs-devel@m.gmane.org; Tue, 22 Apr 2008 03:53:57 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JoDIQ-0000Vv-S6 for emacs-devel@gnu.org; Tue, 22 Apr 2008 03:52:11 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JoDIM-0000SY-BX for emacs-devel@gnu.org; Tue, 22 Apr 2008 03:52:07 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JoDIL-0000SB-RJ for emacs-devel@gnu.org; Tue, 22 Apr 2008 03:52:05 -0400 Original-Received: from fencepost.gnu.org ([140.186.70.10]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JoDIL-0006mi-3X for emacs-devel@gnu.org; Tue, 22 Apr 2008 03:52:05 -0400 Original-Received: from eliz by fencepost.gnu.org with local (Exim 4.67) (envelope-from ) id 1JoBye-0003wH-UH; Tue, 22 Apr 2008 02:27:41 -0400 In-reply-to: <004e01c8a433$680933a0$0200a8c0@us.oracle.com> (drew.adams@oracle.com) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:95746 Archived-At: > From: "Drew Adams" > Cc: , , , > > Date: Mon, 21 Apr 2008 21:43:26 -0700 > > > > > > Whether I access a local Windows drive (even a slow one) or > > > > > a Windows mapped network drive that happens to be in India, > > > > > there is a world of difference. > > > > > > > > No one in their right minds will mount a drive half the > > > > globe away via NFS or similar networking filesystem. > > > > They will always use something like Tramp or ftp. So > > > > this problem simply does not exist in practice. > > > > > > I didn't say anything about NFS or similar; I mentioned > > > Windows mapped network drives. > > > > Same same. Note that I did say ``or similar networking filesystem''. > > So it makes no sense to map a Windows network drive to a remote UNIX file system > with SMB. Only if the drive is ``half the globe away''. > > > However, accessing a mapped network drive is typically > > > much slower than accessing a local hard drive (please - > > > no comments about USB sticks). > > > > That is simply not true in general, even before situations like USB > > sticks are concerned. Of course, if you are in the US and the drive > > is in Asia, that could be true, but that is a very unusual situation. > > According to the network engineers I spoke with today, it is true in general. > It's about the network properties (software and hardware), not necessarily the > distance. It makes sense to me, but I'm no networking expert. You win. I hope this is not just about winning. Network access is indeed slower than local hard disk access, but only by small factors (again, unless the network is extremely slow, which is not what one sees normally). By contrast, access to files for which file-remote-p returns non-nil now is several orders of magnitude slower (10 seconds is not unusual, vs fraction of a second for a networked file). Here's a random example, from an XP SP2 machine where I'm typing this. W: is a networked drive mounted via a corporate network, while D: is a local drive. `ls' is a Windows port of GNU ls from Coreutils 6.9: D:\usr>timep ls -l test total 0 -rw-rw-rw- 1 P0009057 Domain Users 0 2008-04-22 08:49 foobar drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir1 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir10 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir2 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir3 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir4 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir5 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir6 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir7 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir8 drwxrwxrwx 1 P0009057 Domain Users 0 2008-04-22 08:54 tdir9 real 00h00m00.031s user 00h00m00.015s sys 00h00m00.015s D:\usr>timep ls -l w:/ total 0 drwxrwxrwx 1 P0009057 None 0 2007-02-14 20:13 Accounting drwxrwxrwx 1 P0009057 None 0 2008-04-16 08:25 CTI drwxrwxrwx 1 Administrators Domain Users 0 2004-07-21 12:54 Management drwxrwxrwx 1 Administrators Domain Users 0 2007-03-25 11:45 Marketing drwxrwxrwx 1 P0009057 None 0 2008-02-20 10:41 Nob drwxrwxrwx 1 Administrators Domain Users 0 2007-06-20 13:53 Projects drwxrwxrwx 1 Administrators Domain Users 0 2008-03-24 14:46 RealTime drwxrwxrwx 1 P0009057 None 0 2007-06-28 11:22 SIMTECH drwxrwxrwx 1 P0009057 None 0 2007-10-24 15:48 Telecom Solutions drwxrwxrwx 1 Administrators Domain Users 0 2003-10-26 16:19 TSG-QA drwxrwxrwx 1 Administrators Domain Users 0 2008-04-06 11:44 TSG_Marketing Material real 00h00m00.109s user 00h00m00.015s sys 00h00m00.031s This is a 3-fold slowdown for a networked volume, and accessing 11 directories with a plethora of file I/O APIs still takes a fraction of a second. By contrast, just typing "plink fencepost.gnu.org 'ls -l test'" to produce a listing of a directory on a drive ``half a globe away'' from where I physically sit takes 4 seconds, and that's even without the Tramp overhead that could well double or even triple that time. So access to what we now call ``remote'' files is 2 orders of magnitude slower than accessing a local file. Given these numbers, I fail to see how the same simple predicate can satisfy the need for detecting both types of ``remote'' files.