976744 - Does KumaScript load unnecessary modules?

Status: RESOLVED FIXED

(developer.mozilla.org Graveyard :: Performance, defect)

Description

[Florian Scholz (Open Web Docs)]

I enabled KumaScript on my dev vm today (btw, I think it's not documented how to activate it).

First, I have seen lots of 404s, because some modules weren't present in my local database. So I created the dekiscript:* templates. When regenerating a document then, it seems like all of the modules are loaded and executed. Is that necessary? If I see it correctly some of them are empty and do not provide any functionality.

E.g. dekiscript:num only says: 
> <% module.exports = buildAPI({ 
> }); %>

Template:dekiscript:wiki?raw=1    HTTP/1.1 200 11919 (time: 1.96s; sql: 154ms (8q))
Template:dekiscript:uri?raw=1     HTTP/1.1 200 993 (time: 2.62s; sql: 310ms (9q))
Template:dekiscript:string?raw=1  HTTP/1.1 200 2979 (time: 2.79s; sql: 164ms (8q))
Template:dekiscript:page?raw=1    HTTP/1.1 200 3667 (time: 2.77s; sql: 136ms (8q))
Template:dekiscript:web?raw=1     HTTP/1.1 200 1386 (time: 2.96s; sql: 128ms (8q))
Template:dekiscript:xml?raw=1     HTTP/1.1 200 44 (time: 4.12s; sql: 246ms (8q))
Template:dekiscript:num?raw=1     HTTP/1.1 200 44 (time: 3.38s; sql: 335ms (8q))
Template:dekiscript:meta?raw=1    HTTP/1.1 200 44 (time: 3.44s; sql: 345ms (8q))
Template:dekiscript:list?raw=1    HTTP/1.1 200 44 (time: 3.37s; sql: 401ms (8q))
Template:dekiscript:map?raw=1     HTTP/1.1 200 44 (time: 3.63s; sql: 309ms (8q))
Template:dekiscript:num?raw=1     HTTP/1.1 200 44 (time: 3.09s; sql: 225ms (7q))
Template:dekiscript:list?raw=1    HTTP/1.1 200 44 (time: 3.03s; sql: 159ms (7q))
Template:dekiscript:xml?raw=1     HTTP/1.1 200 44 (time: 3.13s; sql: 79ms (7q))
Template:dekiscript:map?raw=1     HTTP/1.1 200 44 (time: 3.39s; sql: 62ms (7q))
Template:dekiscript:meta?raw=1    HTTP/1.1 200 44 (time: 3.46s; sql: 188ms (7q))
Template:dekiscript:xml?raw=1     HTTP/1.1 200 44 (time: 1.82s; sql: 239ms (7q))
Template:dekiscript:list?raw=1    HTTP/1.1 200 44 (time: 2.37s; sql: 208ms (7q))
Template:dekiscript:num?raw=1     HTTP/1.1 200 44 (time: 1.91s; sql: 101ms (7q))
Template:dekiscript:map?raw=1     HTTP/1.1 200 44 (time: 2.19s; sql: 184ms (7q))
Template:dekiscript:meta?raw=1    HTTP/1.1 200 44 (time: 2.37s; sql: 112ms (7q))
Template:dekiscript:date?raw=1    HTTP/1.1 200 346 (time: 2.26s; sql: 183ms (8q))
Template:dekiscript:culture?raw=1 HTTP/1.1 200 44 (time: 2.72s; sql: 233ms (8q))
Template:dekiscript:json?raw=1    HTTP/1.1 200 44 (time: 3.17s; sql: 248ms (8q))
Template:mdn:common?raw=1         HTTP/1.1 200 12005 (time: 2.88s; sql: 292ms (8q))

Some are loaded more than once?

Maybe we already know this or there are other reasons for these requests, but I thought it would be better to file this and ask just in case :)

Comment 1

[Les Orchard [:lorchard]]

Those are the the auto-loaded modules:

https://developer.mozilla.org/en-US/docs/Project:MDN/Kuma/Introduction_to_KumaScript#Auto-loaded_modules

This might need some cache debugging, but kumascript loads all those modules at least on the first few hits. Multiple requests might be explained by kumascript having multiple processes and each needing its own copy of all the modules. And, if you hit shift-reload, it will often reload all these modules in order to make sure to pick up any changes.

Comment 2

[Les Orchard [:lorchard]]

There's also no way to load these modules on-demand, or to know which might be needed ahead of time.

Comment 3

[Florian Scholz (Open Web Docs)]

Okay, interesting. 

> For the most part, these attempt to provide stand-ins for legacy DekiScript features
> to ease template  migration. But, going forward, these can be used to share common
> variables and methods between templates

This is incredibly useful and I am sure we will make use of it when cleaning up our macros. I am wondering if it's worth keeping empty modules from Deki days, though. In other words, if an extra request to an empty module costs us some time and we haven't used these auto-loaded modules for ages now, I think we are fine to get rid of them.

Comment 4

[Les Orchard [:lorchard]]

(In reply to Florian Scholz [:fscholz] (elchi3) from comment #3)
 
> This is incredibly useful and I am sure we will make use of it when cleaning
> up our macros. I am wondering if it's worth keeping empty modules from Deki
> days, though. In other words, if an extra request to an empty module costs
> us some time and we haven't used these auto-loaded modules for ages now, I
> think we are fine to get rid of them.

Well, the "going forward" part is important - there are many methods & bits of data in these modules that are very much still in use. They started as legacy support, but have been expanded upon.

Comment 5

[Florian Scholz (Open Web Docs)]

Okay, I see. I will definitely look into this; pretty interesting!

Feel free to close this, if there there is nothing to improve performance-wise here.

Comment 7

[[github robot]]

Commit pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/956cfe51686c0666bed553578431e26d4a3e33a4
bug 976744 - Stop loading unused DekiScript modules

Comment 8

[Florian Scholz (Open Web Docs)]

Trevor says in https://github.com/mozilla/kuma/pull/2782:

"but it is not a complete fix as the templates also need to be removed form MDN."

https://developer.mozilla.org/en-US/docs/Template:DekiScript:Culture
https://developer.mozilla.org/en-US/docs/Template:DekiScript:Json
https://developer.mozilla.org/en-US/docs/Template:DekiScript:List
https://developer.mozilla.org/en-US/docs/Template:DekiScript:Map
https://developer.mozilla.org/en-US/docs/Template:DekiScript:Meta
https://developer.mozilla.org/en-US/docs/Template:DekiScript:Num
https://developer.mozilla.org/en-US/docs/Template:DekiScript:Xml

Should we delete those now to fix this bug?

Also this page needs content update:
https://developer.mozilla.org/en-US/docs/MDN/Kuma/Introduction_to_KumaScript#Auto-loaded_modules

Comment 9

[David Walsh :davidwalsh]

Nah, there's no reason to delete them -- they're just docs out there like our user pages, etc.  If we ever revert that commit, for whatever reason, we'll want those docs there.