When To Use Static Data - RevoGirl/RevoBoot GitHub Wiki
Introduction
Many people are getting confused – no wonder with so many different compiler directives – and they think to need static data from day one. Wrong! You don't have to use static data at all, when you don't want to use it. This RevoBoot only feature is optional. It is not mandatory. And with that cleared up, let's explain a few other things.
Why Use Static Data?
Static data is as it should be; static. It also makes our code (the booter) smaller, which in turn makes it faster for the BIOS/UEFI to load. Having less code usually also means less bugs and a faster boot time.
We asked Master Chief about this, the man himself who single handed invented this RevoBoot feature, and he assured us that when he started to work on it (back in 2009) that the old SMBIOS code took like 2.5 seconds (2.5 revs on the gray / graphical screen) to finish. In other words he reduced the boot time by over two seconds when he introduced this feature.
RevoGirl has since changed so much of the source code, that it is now almost impossible to measure how fast it became (anything below 55ms is simply too fast).
When To Use Static Data
Like we said earlier; you don't have to use static data. We do because we can do without some of the repetitive actions, like gathering CPU and SMBIOS data which won't change until we install a new / different CPU or make changes in the BIOS/UEFI. Which isn't going to happen on our setups anymore since they are working just fine now.
What Types Of Static Data Are There?
RevoBoot can include three different types of static data, being; CPU, EFI and SMBIOS data. The CPU data will be the same, until you change CPU. SMBIOS data will also be the same, until you change say your RAM. EFI data will be the same for as long as you use the same Graphics card.
You see. Once setup... it can be a good thing to use static data over dynamically gathered data, but again; You do not have to use it. Not at all. In fact we advise people to start with dynamically gathered data from day one, and slowly progress and include static data. One after the other. Not all at the same time. Much easier to debug when things don't want to work.