Issue: VW load 113 files on any xenforo page

On most pages, VaultWiki will at least need to create the wiki tab in the navigation menu. This is lower in vBulletin due to the entire nav tab not being generated on every page, but XenForo creates it in full due to tab drop-down functionality, so here's the break down:

core class 1 file
wiki config 1 file
dependency (forum software) resolution 2 files
create environment 2 files
event listener 2 files (1 public, 1 public+acp)
navbar plugin 1 file
uses some setting values 2 files
permissions for navbar (2 files for processing + 2 files for rules + 2 files for bit values)
needs logged-in user info 2 files
requires db access 4 files
navbar contains links 2 files
generated based on content type 2 files + 1 for each type used (usually +1 page +1 index +1 special)
fetch info needed to build link (1 file + 1 for each content type used - usually +1 page +1 index +1 special +2 dependencies)
avoid queries by checking cache data 2 files (this can also skip 3 files above in best case scenario)
follow replacement rules 1 file (+1 if mbstring is not compiled)
nav tab contains phrases 2 files
nav tab uses templates 2 files
nav tab uses style properties 2 files
convert VaultWiki phrases to XenForo phrases 2 files
check if the page can contain integrations 1 files, unless it can: then we load all the integration rules to check the page against. +1 file for every integratable type installed.
---
total: 41

However, due to:
VaultWiki extends the Forum model +1
VaultWiki extends the Thread model +1
VaultWiki extends the Alert model +1
VaultWiki extends the Router +1
VaultWiki extends the Forum Home view +1
VaultWiki checks for areas used as forum bits +2

which brings us to 48

That is the baseline for VaultWiki on forum home. It will vary upwards based on additional features that are used, and if certain caches are not primed.

If you use the BB-Code parser on any page (you might on forum home with other mods), the baseline is going to almost double. This is due to extensions to the XenForo parser, formatter, abstraction layers that VaultWiki uses to understand them, wiki BB-Code handlers and abstraction layers, syntax manager rules, and autolinks.

I see. It would be really nice if you could review if VW4 on XF can be optimized so that high traffic big boards can run VW4 as smooth as possible.

When we began working on VaultWiki 4, I expressed concern over the push from consumers and the wide adoption of MVC. With MVC, you effectively double or triple the number of files that are executed versus procedural coding, especially with conventional hard disk seek times so high (~8 ms... over 100 files that is almost 1 second). The answer I was given was that most modern web servers are equipped with file system caching and opcode caching, which together would render the hard disk seek times negligible once they were primed. If you are seeing low performance due to file access, it is possible these features are not enabled on your test board.

While I'm sure there are files here and there that are loaded prematurely and that could be deferred, this might account for a 1-5% improvement at the most. VaultWiki 4 was already designed modularly, which means more files, but only what is used is loaded, resulting in lower memory footprint.

Otherwise, the only real optimization if you are looking at file access counts is for us to ditch MVC and move back to procedural.

My dev site does not use LiteSpeed Cache yet, but once live it will and therefore files will be cached.
Even small improvements of 5% make a lot of sense to do, because its the little things that add up on a large site.

I will keep my eye out as I am fixing other bugs to see if some files are loaded too early, but it does not make much sense for us to have a separate "review" of how files are included. It would be very time consuming to review 4,000 product files when there may not even be anything wrong.

I will close this report but make a note that we should keep an eye open for inclusion improvements as we are working on other issues.