Re: Emacs rewrite in a maintainable language

[Taylan Ulrich Bayırlı/Kammer]

David Kastrup <address@hidden> writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> David Kastrup <address@hidden> writes:
>>
>>> address@hidden (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?

Regarding Elisp string munging, probably, since the same C code as
before applies.

>> 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.

Opening a 30 MB IRC log file takes the same amount of felt time as on
upstream Emacs.  Saving it too.

(while (re-search-forward "taylan" nil t) (ignore)) in the same file is
pretty much instant on both.

I think there's simply no speed difference in string munging on
GuileEmacs so far.  It really just uses the existing C "subrs".

Taylan