Re: Not using DOC for ELisp files

[Ken Raeburn]

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.

Ken