Re: Emacs rewrite in a maintainable language

[Taylan Ulrich Bayırlı/Kammer]

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (Taylan Ulrich Bayırlı/Kammer)
>> Cc: Ludovic Courtès <address@hidden>,  Eli Zaretskii
>>  <address@hidden>,  address@hidden
>> Date: Sat, 17 Oct 2015 20:34:15 +0200
>> 
>> > Most relevant candidates are likely file load/save, string display and
>> > stuff like regexp searches through buffers.
>> 
>> Opening a 30 MB IRC log file takes the same amount of felt time as on
>> upstream Emacs.  Saving it too.
>
> Can you time both and show the exact timings?
>
> Also, the file should not be plain ASCII (and probably not UTF-8,
> either), so that decoding the text is included in the comparison.
>
>> (while (re-search-forward "taylan" nil t) (ignore)) in the same file is
>> pretty much instant on both.
>
> Once again, please show exact timings.  "Pretty much instant" could be
> 0.01 sec vs 0.02 sec, which is still twice slower.

Timing things mechanically is difficult when GuileEmacs takes so much
longer to boot.

The slow-downs in GuileEmacs are generally of the nature that cause
slowness of orders of magnitude (i.e. very obvious bugs) and I'm already
pretty sure that GuileEmacs simply uses existing Elisp string/buffer
functionality, so I was merely trying to prove that.

I now created a 300 MiB file with data from /dev/urandom and they still
both take the same amount of time to open it, which is about 3 seconds,
and scrolling through the file, using Isearch, etc. all works fine.  I
hope that's convincing enough.

There are currently some grave performance issues in GuileEmacs, but
they aren't related to string/buffer handling, because it simply uses
the existing C code there.

Taylan