9:42 p.m.
>>>> "Darryl" == Darryl Okahata
<darrylo(a)sr.hp.com> writes:
Darryl> I don't know about NT, but stat() is VERY expensive under Win95.
Darryl> If I recall correctly, a call to stat() takes on the order of
Darryl> milliseconds on a non-MMX P166 (and I think over 10ms), under Win95
Darryl> OSR2. Why, I don't know (this is real/elapsed, and not CPU, time). By
Darryl> bypassing stat(), and using the native Win32 system calls, my dired-in-C
Darryl> changes were able to get a significant performance improvement.
That's why I asked if there isn't a way to compute file-directory-p
without doing a full stat under Win32. Don't DOS directories store
that information in the directory entry?
--
Cheers =8-} Chipsy
Friede, Völkerverständigung und überhaupt blabla
2:55 a.m.
New subject: Startup speed: Still too many stats?
A long while back, sperber(a)informatik.uni-tuebingen.de (Michael Sperber
[Mr. Preprocessor]) wrote:
> I don't know about NT, but stat() is VERY expensive
under Win95.
> If I recall correctly, a call to stat() takes on the order of
> milliseconds on a non-MMX P166 (and I think over 10ms), under Win95
> OSR2. Why, I don't know (this is real/elapsed, and not CPU, time). By
> bypassing stat(), and using the native Win32 system calls, my dired-in-C
> changes were able to get a significant performance improvement.
That's why I asked if there isn't a way to compute file-directory-p
without doing a full stat under Win32. Don't DOS directories store
that information in the directory entry?
There is a way to do file-directory-p without doing a stat() under
Win32, but I don't know if it will save any time. (Actually, I added
this to my local copy of XEmacs, but I really haven't done any timings.
I certainly haven't noticed any speed difference. I'll try to do some
timings tonight.)
[ Going off on a complete tangent, Insight (http://www.insight.com)
seems to have a great special on old 200MHz Pentium Pros, which might
make great Unix boxes. Toshiba's getting out of the desktop business,
and their Equium 6200M is going for $800, without monitor. You get a
4GB fast/wide SCSI disk (the controller is supposedly based upon the
AHA-7880), an Intel EtherExpress PRO/100B LAN, 32MB EDO/ECC RAM, 12X
IDE CDROM, ATI Rage 3D video, USB ports, & Windows NT 4.0. I've also
heard that it's using an Intel dual PPro motherboard, so you can have
SMP if you can find a matching CPU. The downsides seem to be that the
F/W SCSI disk is a Micropolis (no longer in business), that the disk
needs firmware upgrades to work with Unix, and that there is no
external SCSI connector. I ordered one, and we'll see how it works
out. ]
-- Darryl Okahata
Internet: darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
3:46 p.m.
New subject: Startup speed: Still too many stats?
NTemacs has a patch now that caches stats so direds are somewhat
faster. It was in support of dired, not startup, so I don't know if it
applies to your particular problem.
I don't know the technical details, but there was a long conversation
about it on the ntemacs mailing list a couple of months ago. You might
take a look.
A dired over the network is very very bad. I find the following
useful, especially combined with drag-and-drop.
;; ----------------------------------------------------------------
;; add "explore" command to pop up the Windows explorer.
(defvar explorer-program-name
(let ((winder (getenv "windir")))
(if winder
(expand-file-name "explorer.exe" winder)
"explorer.exe"))
"The name of the program that's executed to Explore a directory.")
(defvar explorer-options "" ;;"/e,/idlist,"
"*Options to explorer.exe for \\[dired-explore]
Other possible values: \"/e,/idlist,\" or \"/e,/root,\".
Note the trailing comma.")
(defun explore (file)
"Run the Windows Explorer on the given directory."
(interactive "DExplore Directory: ")
(let ((win32-start-process-show-window t) ;; v19
(w32-start-process-show-window t) ;; v20
(directory-sep-char ?\\)
(win32-quote-process-args nil)
(w32-quote-process-args nil)
)
(let* ((efile (expand-file-name file)))
(setq file (file-name-as-directory efile))
(start-process "explorer-process"
nil
explorer-program-name
(concat explorer-options
efile)))))
(defun dired-explore ()
"In dired, run the Windows Explorer on the directory named at point."
(interactive)
(explore (dired-get-filename)))
(define-key dired-mode-map "E" 'dired-explore)
(define-key dired-mode-map [menu-bar operate dired-explore]
'("Explore (directory)" . dired-explore))
7:08 p.m.
New subject: Startup speed: Still too many stats?
Larry Smith <lsmith(a)cio2000.eds.com> wrote:
A dired over the network is very very bad. I find the following
useful, especially combined with drag-and-drop.
I don't see a problem with dired in XEmacs & network drives. Can
you elaborate?
On a P150 MMX laptop running Win95 OSR2, doing a dired of
c:\windows\system (~1120 files) takes around 10-11 seconds.
On the same system, doing a dired of a network drive (~950 files)
takes 9-10 seconds. The lan card is a slow PCMCIA (non-cardbus) 10BT
card. The network drive is on an NT box running 4.0sp3, and the
remote directory scanned is c:\winnt\system32 (on the NT box).
Both of these times are comparable, and so I don't see any
problem. Dired would run even faster if I compiled XEmacs without
debugging turned on.
However, this is with XEmacs debugging turned on, which slows down
XEmacs, but with the dired-in-C code enabled. This is also with some
dired patches (for performance increases) that I recently submitted to
the dired maintainer, but these patches affect all uses of dired, and
would make no difference between a local or network drive.
-- Darryl Okahata
Internet: darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
10:05 p.m.
New subject: Slow stat (was Startup speed: Still too many stats?)
I want to make it very clear that this is NOT an FSF NTEmacs vs
NTXemacs issue. It's just that Microsoft's implementation of the stat
system call is very slow. It's worse over a network.
Microsoft's "dir" command and the Explorer don't do stat. They get less
information, and use some other mechanism I don't understand.
I have it on my list of things to do to make a version of dired that
uses "dir" instead of "ls -l". When in Rome... Like I said, it has
less information, but it's SO much faster! Has anyone already done
it?
I reconstructed my timing experiments.
I have a directory that contains 5000 files, which I replicated on my
local disk and on a file server (marshall, who is a router-hop away).
NTEmacs has a lisp function that does a directory-files, then a
file-attributes for each file. It's for people who don't have unix
emulator tools. (I don't know if NTXemacs has it.) I used it for the
dired timing test.
For comparison, I did various "ls" commands in a DOS command prompt
window. I'm using Cygnus' cygwin32 b19 ls.exe. I'm running NT 4.0
service pack 3.
Command time
dired d:/temp/big 30 sec
ls -l //d/temp/big 18 seconds
dir d:\temp\big 4 seconds
Explorer d:\temp\big 2 seconds
dired //marshall/homes/temp/big 15 MINUTES
ls -l //marshall/homes/temp/big 13 MINUTES
dir \\marshall\homes\temp\big 15 seconds
Explorer \\marshall\homes\temp\big 11 seconds
Larry
10:41 p.m.
New subject: Slow stat (was Startup speed: Still too many stats?)
Larry Smith <lsmith(a)cio2000.eds.com> wrote:
I want to make it very clear that this is NOT an FSF NTEmacs vs
NTXemacs issue. It's just that Microsoft's implementation of the stat
system call is very slow. It's worse over a network.
I wasn't making this into an NT Emacs vs XEmacs debate. I'm saying
that *I* don't see a problem with *****XEmacs*****. If you enable the
dired-in-C enhancements in *****XEmacs*****, you should see performance
comparable to "dir". The dired-in-C enhancements bypass the use of
stat() (if you think it's bad under NT, you haven't seen Win95), and use
FindFirstFile()/FindNextFile() directly. It's very fast.
Note, however, that dired in XEmacs is pretty inefficient. With
the current dired, most of the time is spent doing an "indent-region"
(and not obtaining the actual directory contents). To speed things up,
try applying the appended patch to dired.el (I just submitted this to
the dired folks).
-- Darryl Okahata
Internet: darrylo(a)sr.hp.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Hewlett-Packard, or of the
little green men that have been following him all day.
===============================================================================
*** dired.el.~1~ Thu Feb 26 15:33:42 1998
--- dired.el Sun May 24 12:56:38 1998
***************
*** 1773,1779 ****
(widen)
(erase-buffer)
(dired-readin-insert dir-or-list wildcard)
- (dired-indent-listing (point-min) (point-max-marker))
;; We need this to make the root dir have a header line as all
;; other subdirs have:
(goto-char (point-min))
--- 1773,1778 ----
***************
*** 1825,1831 ****
;; insert all files listed in the cdr -- the car is the passed-in directory
;; list.
(let ((opoint (point))
! (insert-directory-program dired-ls-program))
(if (consp dir-or-list)
(mapcar
(function
--- 1824,1830 ----
;; insert all files listed in the cdr -- the car is the passed-in directory
;; list.
(let ((opoint (point))
! (insert-directory-program dired-ls-program) end)
(if (consp dir-or-list)
(mapcar
(function
***************
*** 1833,1839 ****
(insert-directory x switches wildcard)))
(cdr dir-or-list))
(insert-directory dir-or-list switches wildcard full-p))
! (dired-insert-set-properties opoint (point)))
(setq dired-directory dir-or-list))
(defun dired-frob-dir-list (dir-list)
--- 1832,1840 ----
(insert-directory x switches wildcard)))
(cdr dir-or-list))
(insert-directory dir-or-list switches wildcard full-p))
! (setq end (point-marker))
! (dired-indent-listing opoint end)
! (dired-insert-set-properties opoint end))
(setq dired-directory dir-or-list))
(defun dired-frob-dir-list (dir-list)
11:41 p.m.
New subject: Slow stat (was Startup speed: Still too many stats?)
Darryl,
I just applied your patche on my Windows 95 system. The difference is awesome.
Thanks!
david
Note, however, that dired in XEmacs is pretty inefficient.
With
the current dired, most of the time is spent doing an "indent-region"
(and not obtaining the actual directory contents). To speed things up,
try applying the appended patch to dired.el (I just submitted this to
the dired folks).
-- Darryl Okahata
11:23 p.m.
New subject: Slow stat (was Startup speed: Still too many stats?)
There's no "stat" in Win32 at all.
There's an implementation of stat in C library. XEmacs has its own
implementation.
The good thing is to improve our implemenation of stat().
The Right Thing is to build a filesystem abstraction, which would
use advantages of file system API set, instead of riding the dirty
way of emulation of UNIX-style api set.
Have a slice of a pie in the sky.
Kirill
9791
days inactive
9810
days old
7 comments
5 participants
participants (5)
-
Darryl Okahata -
David Bush -
Kirill M. Katsnelson -
Larry Smith -
Michael Sperber