[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Not using DOC for ELisp files

From: Ken Raeburn
Subject: Re: Not using DOC for ELisp files
Date: Fri, 7 Jan 2022 17:59:25 -0500
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1

On 2022-01-03 09:30, Eli Zaretskii wrote:
Date: Mon, 3 Jan 2022 08:48:03 -0500
From: Ken Raeburn <raeburn@raeburn.org>

Another piece I recall looking at, which I don't remember if I brought
up on the list at the time, was moving the C based doc strings into the
generated .o files and the executable
Did you only think about ELF executables, or did you consider how to
do this with any binary formats we support?

As I recall, it was a generic approach, putting the strings into char arrays linked in at the C level during compilation. For variables, I think there was some indirection via an array index, to avoid increasing Lisp_Symbol size while also not creating all the doc strings as Lisp strings up front. I don't recall if that part got completed; I tackled function docs first.

The annoying part was, it adds a generated header per C source file for these strings. I was looking at whether it could be done without doing so, but make-docfile tacks on the "(fn THIS-ARG THAT-ARG ...)" bit for function documentation which can't _exactly_ be done with preprocessor hacks; cpp has no "upcase" function, though tweaks to the runtime support could work around that. And DEFVAR docs need to be pulled out and (as mentioned above) stuffed into an array of strings.

There was an optimization I did, for platforms supporting the "section" attribute extension (at least MacOS and the GNU tools on ELF), to group together the strings in the object file (and hopefully the executable) so that, if the doc strings weren't actually used, none of those pages need be paged in from disk, because they aren't intermixed with other data (except maybe at the ends of the range). But if that support isn't available, the rest should still work fine. And if the non-Lisp doc strings amount to less than a megabyte, as I think an earlier email in this thread indicated, the memory cost of not doing this apparently isn't huge anyway.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]