It could be worse 😂

I agree that this topic matters, given specifications are the ground truth (or the desire is for them to be the ground truth) for the validation and operation of the API and the language, and if people can access it with less friction, whether from low power mobile or from a powerful machine that's simply occupied with other tasks, it can be helpful for developers, especially given the current situation with certain text generation systems hallucinating at their suggestions where search can easily lead people to spec for a better reference.

To replicate the issue, I made a memory profile on Safari (Sonoma 14.5), and on M1, I see 260-270 MB usage for both API and WGSL. As a simple attempt, I tried a few HTML minification tools, and these didn't translate to a meaningful reduction in file size but they reduced memory usage by around ~10MB for API spec.

However, I could not replicate the 50MB memory usage for the raw text version; the following txt files gave 200MB memory usage on Safari. Maybe I should also try on Chrome.

% pandoc -f html -t plain index.html -o output.txt
% pandoc -f html -t plain wgsl/index.html -o output_wgsl.txt
% ls -lh index.html 
-rw-r--r--  1 oguz  staff   3.8M Jul 14 23:04 index.html
% ls -lh output.txt 
-rw-r--r--  1 oguz  staff   631K Jul 14 23:29 output.txt
% ls -lh wgsl/index.html 
-rw-r--r--  1 oguz  staff   2.4M Jul 14 23:04 wgsl/index.html
% ls -lh output_wgsl.txt 
-rw-r--r--  1 oguz  staff   602K Jul 14 23:33 output_wgsl.txt

Recognizing the other priorities wrt spec development, the improvements might come a bit later as we need to make sure any change should be compatible with publication flows that we have. Lazy loading might be an obvious way, but it is also important to make sure the page supports reader tools, printing, etc., or at least have versions for those.

Thank you for the reply. For the raw text I merely copied the entire text content (Ctrl-A Ctrl-C) and pasted it into the empty body of an html file. I'm sure a functional document would require considerably more content than that.

It "randomly" changes from 200 to 600 MB. This must be Chrome irresponsibly taking up as much RAM as it can to speed up page browsing, achieving the opposite effect. I'm amazed there's not a simple way to just tell the browser to limit the maximum memory available for that tab. The document is perfectly functional and fast with "just" 200 MB.

I am glad this is seen as something that matters, even if not a priority right now. The Vulcan spec instantly gobbles up 730 MB on my machine. 2 GB is outrageous.

It certainly seems outrageous to claim to need ~500meg to display the spec.

I don't now how Safari, Firefox, and Chrome account memory but I just want to point out, a M1 Mac has a native screen resolution of 4480x2520 at 32bits per pixel that's 45meg by itself, single buffered.

Saving the entire spec to a PDF and loading up the PDF in Chrome shows only ~25meg usage so that might be a temp workaround.

Also, turning off JavaScript seemed to take it down to 369meg. With it off, certain cross references like this, don't show up.

Running in guest mode (so no extensions) made it 343meg. Turning off JavaScript there made it 216meg