GNU bug report logs - #46881
28.0.50; pdumper dumping causes way too many syscalls

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> gmail.com>
Cc: 46881 <at> debbugs.gnu.org, dancol <at> dancol.org, eggert <at> cs.ucla.edu
Subject: bug#46881: 28.0.50; pdumper dumping causes way too many syscalls
Date: Fri, 05 Mar 2021 14:06:55 +0200

> From: Pip Cet <pipcet <at> gmail.com>
> Date: Fri, 5 Mar 2021 09:54:32 +0000
> Cc: Daniel Colascione <dancol <at> dancol.org>, eggert <at> cs.ucla.edu, 46881 <at> debbugs.gnu.org
> 
> My patch:
> 
> real    0m1.988s
> user    0m1.916s
> sys    0m0.073s
> 
> fwrite-based patch:
> 
> real    0m3.576s
> user    0m2.571s
> sys    0m1.006s

30% slowdown and 1.5 sec absolute time difference doesn't sound bad
enough to me to justify a homemade solution.  I say let's go with
stdio.

> > > Also, we're not currently using fseek-and-write anywhere in Emacs.
> >
> > I don't see why this would be important.
> 
> Because the stream returned by emacs_fopen might not be generally seekable?

I don't see how that could happen.

> > Since we open the file in
> > binary mode, fseek should work correctly even on non-Posix systems.
> 
> I guess I should have used emacs_fopen :-)

Yes, of course.  Especially as with fopen there are problems with
non-ASCII file names on MS-Windows.

> By preparing the data in memory and writing it in one go, which
> doesn't require any of the major complications of implementing
> buffered streams.

There are no complications I can see, not in our sources.  (And you
don't actually write it in one go anyway, see emacs_full_write.)

So let's go with the stdio solution, please.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.