GNU bug report logs - #34350
27.0.50; ediff-revision broken with SVN backend + non ascii chars both in directory and in filename

Previous Next

Full log

Message #56 received at 34350 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 34350 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#34350: 27.0.50;
 ediff-revision broken with SVN backend + non ascii chars both in
 directory and in filename
Date: Sat, 09 Feb 2019 09:03:08 -0500

>> Why should reading from a pipe be slower than from a file?
> Because we read in small chunks,

I understand that what we currently do, but is it really inevitable?
I know you can't transfer an arbitrarily large text with a single `write`
at one end of a pipe and a single `read` at the other (contrary to what
happens with files), but it should be possible to use chunks large
enough that the efficiency is comparable.

> and need to enlarge the gap each time.

Yes, this used to be a real problems in set-buffer-multibyte (with O(N²)
behavior), but nowadays it should be a relatively small constant factor.
Of course, if needed, we could provide some way for the Elisp code to
"preallocate" space to avoid resizing the buffer too many times.

[ Goes on dreaming about a buffer representation made of a tree of
  immutable text-chunks... ]

> OK, so we basically agree.  I will try to remove the cruft from some
> of that, thanks for the feedback.

Right.   Maybe we could improve the backend API, but that's a side
problem: the real pressing problem is just cruft and should not be too
hard to fix.


        Stefan

Previous Next

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