Re: Emacs rewrite in a maintainable language

[David Kastrup <dak@gnu.org>]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> David Kastrup <dak@gnu.org> writes:
>
>> taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:
>>
>>> I haven't followed the whole discussion but I'd like to remind that
>>> GuileEmacs already runs currently, and from what I know none of the
>>> problems it faces are related to string handling.  It just lets Elisp
>>> strings be a separate data type.
>>>
>>> I guess the discussion was about rewriting bigger parts of Emacs in
>>> Guile-Scheme, which might be one possible way to go forward but not
>>> necessary.
>>>
>>> Most of the benefits in e.g. http://www.emacswiki.org/emacs/GuileEmacs
>>> apply without having to solve the string problem.  Specifically, from
>>> the overview section, the first two points and half of the third should
>>> apply I think.
>>
>> The first two points concern efficiency.  Emacs is _all_ about working
>> with strings, and the last report of GuileEmacs stated something like
>> GuileEmacs being about an order of magnitude slower specifically because
>> of having to special-case Emacs strings and buffers.
>>
>> Emacs is first and foremost an editor.  Substantial increases of
>> efficiency in most general programming areas at the cost of abysmal
>> performance in text processing are not going to make the race.
>
> I think you're misremembering.

So performance is comparable?

> It might be that you have strings in mind because not being able to
> serialize Elisp strings means having to compile everything at each
> startup, making startup slow.  And maybe you have buffers in mind
> because buffer-local variables and other weird binding semantics of
> Elisp need special handling.
>
> Neither is related to the run-time performance of string handling, of
> course.
>
> Hmm, what would be a good benchmark of Elisp string handling that
> won't be affected by the performance of dynamic binding of variables
> or other such things?  I'd like to just test it instead of
> hypothesize.

Most relevant candidates are likely file load/save, string display and
stuff like regexp searches through buffers.

-- 
David Kastrup