When using a modpack with quite a few mods the load speeds can take a while, especially if you don't have a great CPU. After thinking about the process of loading the modpack I thought it was quite inefficient to have to load the mods every time on startup and then unload them when you're clearly going to load them back up again next time you want to play. I was wondering if there was some way to "compile" a modded minecraft instance or "freeze" the instance's state when saving and quitting instead of unloading the mods so that the next time you want toplay it doesn't need to load the mods again.[/p]
Googling "how to compile a minecraft instance" just brings up guides on how to compile a minecraft mod and googling "how to freeze a minecraft instance" brings up guides on how to fix minecraft freezing on you. I've reached the extent of my capabilities here.[/p]
disclaimer: vanilla 1.12 and IDE dev-launched packs are guesses, not actually tested. Also, pre, mid, and post don't refer to any exact loading stages, it's an estimate from the time the game window opens, loading bar appears, main menu appears
SUMMARY FINDINGS
2022: 1.18.0 quilt discord quote - "the two big time-consumers are asset loading, and datafixer building." DFU (jan 2021 0.1 release! its very new!) fixes DF building. asset loading in vanilla is very optimized in newer mc (post 1.12) to the point any extra might not be needed for a few seconds gain
2021 december: dashloader!! fabric only 3.0-rc10 for 1.17, 1.18. v1 was created may 2021. " caches the modelmanager while accelerating the other components of the minecraft client initialization stack"
p.s dashloader 2022 forge support - no status on this, forge isn't as open as fabric to work off the shelf with dashloader
2016 (1.12.2 time) official forge dev claims 80% of preload is stuff that cant be cached :upload gpu textures, generating runtime code [below reddit]
I'm not a mc dev but I've been googling the same sort of thing for the last week, you might enjoy reading what others have said. Note some sources are a few years old:
"Caching or compiling" is the right idea, but modpacks change more often than you think (popular ones are updated weekly) and there's always something that breaks some small compatibility, ultimately needing a from-scratch boot up.
re caching - quote from a redwoods mod dev: "Note that Forge's multithreaded loading doesn't support parallel registry events, which are where a huge portion of the modded startup time lies. The other huge portion is resource loading, which is in vanilla and parallel already. I doubt that forge's multithreading will yield as huge of a benefit as some may expect."
There are mods that specifically speed up boot time (rather than being a client/server ingame optimization), a modern and common one being LazyDFU
DashLoader is a modern (supports fabric 1.17.x) caching mod
What I haven't seen is a table or graph showing the distribution and duration of the steps mod loaders do when loading the game, which would be nice to see. When I load one of the popular forge 1.17 modpacks, the normal startup time is 2m5s, and I notice "atlas stitching" is a good 30 second chunk of that. You can see the code it runs on github/forge
User h121 posted on both forge and bdcraft forums, and the responses there are informative between 3-4 people, with the ending comment just saying "code support for it youself"
Interestingly, when you add optifine it freezes for exactly 2 mins at the end of the loading process, and checking debug.log I noticed all it says is:
2016 (1.12.2 time) official forge dev claims 80% of preload is stuff that cant be cached :upload gpu textures, generating runtime code [below reddit]
Is a blatant lie from the forge dev cus they are too lazy to fix it. Lets assume you are me, i have a SSD that can read 3 GB/s, that means if all forge had to do was to read 9 GB post compiled data, assuming its a 1:1 copy of what's in the ram, it should take minimum 3 seconds to load the pack. But no, since forge does not save anything it have to redo it every single time. "but modepacks can change". Then just check for a change, and only if it does detect a change, it redoes it.
Like how come i can wake up my computer from hibernation in a handfull of seconds? Where it has saved the ram onto storage, and then reads it again. But it takes forge, doing essentially the same thing, several hundred times longer? Cus it reinvents the wheel every time, in this case optimizing the data into atlases and what not.
I know this is an old thread, but Google sent me here and I too suffer from poor Forge load times. I'm on a HP Omen laptop (<4 years old) with SSD and 16 GB of RAM. I make sure 10 GB of RAM is free and nothing CPU Intensive is running (CPU < 20%) before launching Minecraft 1.18.2 using a Forge modpack with 130+/- mods and this specific mod takes 10-15 minutes to launch to the Minecraft start screen, loading a < 100 MB world takes about 5 minutes.
I made the following 2 changes and noticed a significant performance boost, about half the launch/load time. LazyDFU [Forge] and FastLoad.
The only real way to minimize load time is to use old-school "jar" modding, which precompiles everything with the source code (which is more or less what the OP is talking about, where Forge would load and construct all the mods in memory and write the "image" to disk (IDK if the JVM supports loading a true memory image but a jar with all the class files and stitched textures would work), using the checksums of the mods in the mods folder to detect changes, which would require recompiling); my own extensive mod for 1.6.4, which adds over 500 new blocks/items/biomes/mobs/etc, takes only a second or two to launch, minus the time the launcher takes to "prepare" the game (as seen when comparing launch speed in MCP and in the launcher, the following is for the game itself, via MCP; the launcher recreates the assets for legacy versions on every launch, an issue which Mojang has unfortunately decided is "cannot reproduce" when they just have to look at the timestamps of the files in ".minecraft\assets\virtual\legacy". Aside from that, the natives that the game uses are recreated for any version):
19:25:39 - 2023-01-24 19:25:39 [CLIENT] [INFO] Setting user: TheMasterCaver
19:25:39 - 2023-01-24 19:25:39 [CLIENT] [INFO] (Session ID is null)
19:25:40 - 2023-01-24 19:25:40 [CLIENT] [INFO] LWJGL Version: 2.9.0
19:25:40 - 2023-01-24 19:25:40 [CLIENT] [INFO] Reloading ResourceManager: Default, ModTextures
19:25:40 -
19:25:40 - Starting up SoundSystem...
19:25:41 - Initializing LWJGL OpenAL
19:25:41 - (The LWJGL binding of OpenAL. For more information, see http://www.lwjgl.org)
19:25:41 - OpenAL initialized.
Also, modloaders, as well as mods in general and newer vanilla versions, are simply terribly coded; the chart in skeleshadows's post says it all - why does Forge with no mods take 4 times longer to start up?! FoamFix also claims that Forge with just itself runs worse than vanilla, hence there is no point in making a "vanilla" version:
Porting it to vanilla would have very few benefits, as vanilla by itself is more efficient than even Forge+FoamFix.
This is self-explanatory - despite all the changes and additions I've made to world generation TMCW takes considerably less time to create a new world than even vanilla 1.6.4, much less vanilla 1.13 (the most recent version I've run) - despite not being multithreaded at all (besides the client-server model; since 1.13 world generation is multithreaded, and many other things):
1.6.4 (5 seconds):
2021-02-04 09:00:24 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2021-02-04 19:00:24 [SERVER] [INFO] Generating keypair
2021-02-04 19:00:24 [SERVER] [INFO] Converting map!
2021-02-04 19:00:24 [SERVER] [INFO] Scanning folders...
2021-02-04 19:00:24 [SERVER] [INFO] Total conversion count is 0
2021-02-04 19:00:24 [SERVER] [INFO] Preparing start region for level 0
2021-02-04 19:00:25 [SERVER] [INFO] Preparing spawn area: 9%
2021-02-04 19:00:26 [SERVER] [INFO] Preparing spawn area: 29%
2021-02-04 19:00:27 [SERVER] [INFO] Preparing spawn area: 57%
2021-02-04 19:00:28 [SERVER] [INFO] Preparing spawn area: 83%
2021-02-04 19:00:29 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 223 at (226.5, 75.0, 256.5)
2021-02-04 19:00:29 [SERVER] [INFO] TheMasterCaver joined the game
TMCW (3 seconds):
2021-02-06 17:53:07 [SERVER] [INFO] Starting integrated minecraft server version 1.6.4
2021-02-06 17:53:07 [SERVER] [INFO] Generating keypair
2021-02-06 17:53:07 [SERVER] [INFO] Converting map!
2021-02-06 17:53:07 [SERVER] [INFO] Scanning folders...
2021-02-06 17:53:07 [SERVER] [INFO] Total conversion count is 0
2021-02-06 17:53:07 [SERVER] [INFO] Preparing start region for level 0
2021-02-06 17:53:08 [SERVER] [INFO] Preparing spawn area: 14%
2021-02-06 17:53:09 [SERVER] [INFO] Preparing spawn area: 52%
2021-02-06 17:53:10 [SERVER] [INFO] TheMasterCaver[/127.0.0.1:0] logged in with entity id 657 at (-4.5, 70.0, -215.5)
2021-02-06 17:53:10 [SERVER] [INFO] TheMasterCaver joined the game
I haven't run any newer versions but I've been told that TMCW runs far better, and even with a lot of modern optimization mods (TMCW has none, other than itself) 1.16 only came close:
Amazing work falls very short, I'm completely impressed at what you accomplished with TMCW, the game runs at 180+ fps on max settings (1.18 barely hits 40 on modest settings, 1.16.5 with a lot of performance mods gets close to that but with choppier feel) with all that extra content of incredible quality.
Memory usage is also astoundingly low - around 20 MB baseline, with loaded chunks taking up anything above this (variable depending on terrain), and is actually lower, especially allocation-wise, than vanilla, in sharp contrast to newer versions, since 1.8, which allocates objects like no tomorrow, and this is only worsened with mods; this post claims that even modded 1.3 needed over 500 MB to just launch, yet TMCW (which uses the client-server model) runs with only 256 MB with no issues on average settings, 512 MB at max settings (what does any mod even need multiple GBs for? I'd be interested in a VisualVM analysis of such a modpack, or even just a modern vanilla version. I've also used VisualVM to diagnose and fix memory leaks, another source of abnormally high resource usage, and see what code is taking the most time).
Unfortunately, the common practice seems to be "it works well enough by itself on my modern high-end system so I won't bother making any optimizations, however minor" (my computer's hardware dates back to 2012-14 and a modern system would be at least 2-3x faster in every aspect, even single-thread performance, which has increased the least), leading to "Wirth's Law" (software demands increase as fast or faster than hardware capabilities).
Also, nothing is more insane than the launcher itself, which is literally 4 times the size of the entire game, even larger if you include all its files (besides launcher.dll)!
For the size of the game itself I used MCP, which only copies over the necessary files for 1.6.4 (assets, libraries, Minecraft.jar, natives); this is for vanilla 1.6.4 but TMCW only increases the size of the jar by about 2 MB, which is less than just 1.8 (the so-called "bountiful update") by itself despite adding many times more content:
Googling "how to compile a minecraft instance" just brings up guides on how to compile a minecraft mod and googling "how to freeze a minecraft instance" brings up guides on how to fix minecraft freezing on you. I've reached the extent of my capabilities here.[/p]
EDIT APRIL 2022:
disclaimer: vanilla 1.12 and IDE dev-launched packs are guesses, not actually tested. Also, pre, mid, and post don't refer to any exact loading stages, it's an estimate from the time the game window opens, loading bar appears, main menu appears
SUMMARY FINDINGS
2022: 1.18.0 quilt discord quote - "the two big time-consumers are asset loading, and datafixer building." DFU (jan 2021 0.1 release! its very new!) fixes DF building. asset loading in vanilla is very optimized in newer mc (post 1.12) to the point any extra might not be needed for a few seconds gain
2021 december: dashloader!! fabric only 3.0-rc10 for 1.17, 1.18. v1 was created may 2021. " caches the modelmanager while accelerating the other components of the minecraft client initialization stack"
p.s dashloader 2022 forge support - no status on this, forge isn't as open as fabric to work off the shelf with dashloader
2016 (1.12.2 time) official forge dev claims 80% of preload is stuff that cant be cached :upload gpu textures, generating runtime code [below reddit]
I'm not a mc dev but I've been googling the same sort of thing for the last week, you might enjoy reading what others have said. Note some sources are a few years old:
"Caching or compiling" is the right idea, but modpacks change more often than you think (popular ones are updated weekly) and there's always something that breaks some small compatibility, ultimately needing a from-scratch boot up.
re caching suggestion: official forge dev quote "We've looked at doing this. 80% of the time is spent doing stuff we can't cache"
re caching - quote from a redwoods mod dev: "Note that Forge's multithreaded loading doesn't support parallel registry events, which are where a huge portion of the modded startup time lies. The other huge portion is resource loading, which is in vanilla and parallel already. I doubt that forge's multithreading will yield as huge of a benefit as some may expect."
There are mods that specifically speed up boot time (rather than being a client/server ingame optimization), a modern and common one being LazyDFU
DashLoader is a modern (supports fabric 1.17.x) caching mod
What I haven't seen is a table or graph showing the distribution and duration of the steps mod loaders do when loading the game, which would be nice to see. When I load one of the popular forge 1.17 modpacks, the normal startup time is 2m5s, and I notice "atlas stitching" is a good 30 second chunk of that. You can see the code it runs on github/forge
This gist, a listing of all performance mods since 1.7 to now, which also has a profiling/debugging section
reddit r/feedthebeast - discussion on forge pre 1.13 load time
User h121 posted on both forge and bdcraft forums, and the responses there are informative between 3-4 people, with the ending comment just saying "code support for it youself"
Interestingly, when you add optifine it freezes for exactly 2 mins at the end of the loading process, and checking debug.log I noticed all it says is:
Notice the 2 minute gap in log times. Optifine is closed source so we can't proactively investigate
Is a blatant lie from the forge dev cus they are too lazy to fix it. Lets assume you are me, i have a SSD that can read 3 GB/s, that means if all forge had to do was to read 9 GB post compiled data, assuming its a 1:1 copy of what's in the ram, it should take minimum 3 seconds to load the pack. But no, since forge does not save anything it have to redo it every single time. "but modepacks can change". Then just check for a change, and only if it does detect a change, it redoes it.
Like how come i can wake up my computer from hibernation in a handfull of seconds? Where it has saved the ram onto storage, and then reads it again. But it takes forge, doing essentially the same thing, several hundred times longer? Cus it reinvents the wheel every time, in this case optimizing the data into atlases and what not.
I know this is an old thread, but Google sent me here and I too suffer from poor Forge load times. I'm on a HP Omen laptop (<4 years old) with SSD and 16 GB of RAM. I make sure 10 GB of RAM is free and nothing CPU Intensive is running (CPU < 20%) before launching Minecraft 1.18.2 using a Forge modpack with 130+/- mods and this specific mod takes 10-15 minutes to launch to the Minecraft start screen, loading a < 100 MB world takes about 5 minutes.
I made the following 2 changes and noticed a significant performance boost, about half the launch/load time. LazyDFU [Forge] and FastLoad.
https://www.curseforge.com/minecraft/mc-mods/lazy-dfu-forge
https://www.curseforge.com/minecraft/mc-mods/fastload
Hope this helps someone else...
The only real way to minimize load time is to use old-school "jar" modding, which precompiles everything with the source code (which is more or less what the OP is talking about, where Forge would load and construct all the mods in memory and write the "image" to disk (IDK if the JVM supports loading a true memory image but a jar with all the class files and stitched textures would work), using the checksums of the mods in the mods folder to detect changes, which would require recompiling); my own extensive mod for 1.6.4, which adds over 500 new blocks/items/biomes/mobs/etc, takes only a second or two to launch, minus the time the launcher takes to "prepare" the game (as seen when comparing launch speed in MCP and in the launcher, the following is for the game itself, via MCP; the launcher recreates the assets for legacy versions on every launch, an issue which Mojang has unfortunately decided is "cannot reproduce" when they just have to look at the timestamps of the files in ".minecraft\assets\virtual\legacy". Aside from that, the natives that the game uses are recreated for any version):
Also, modloaders, as well as mods in general and newer vanilla versions, are simply terribly coded; the chart in skeleshadows's post says it all - why does Forge with no mods take 4 times longer to start up?! FoamFix also claims that Forge with just itself runs worse than vanilla, hence there is no point in making a "vanilla" version:
This is self-explanatory - despite all the changes and additions I've made to world generation TMCW takes considerably less time to create a new world than even vanilla 1.6.4, much less vanilla 1.13 (the most recent version I've run) - despite not being multithreaded at all (besides the client-server model; since 1.13 world generation is multithreaded, and many other things):
TMCW (3 seconds):
1.13 (15 seconds):
I haven't run any newer versions but I've been told that TMCW runs far better, and even with a lot of modern optimization mods (TMCW has none, other than itself) 1.16 only came close:
Memory usage is also astoundingly low - around 20 MB baseline, with loaded chunks taking up anything above this (variable depending on terrain), and is actually lower, especially allocation-wise, than vanilla, in sharp contrast to newer versions, since 1.8, which allocates objects like no tomorrow, and this is only worsened with mods; this post claims that even modded 1.3 needed over 500 MB to just launch, yet TMCW (which uses the client-server model) runs with only 256 MB with no issues on average settings, 512 MB at max settings (what does any mod even need multiple GBs for? I'd be interested in a VisualVM analysis of such a modpack, or even just a modern vanilla version. I've also used VisualVM to diagnose and fix memory leaks, another source of abnormally high resource usage, and see what code is taking the most time).
Unfortunately, the common practice seems to be "it works well enough by itself on my modern high-end system so I won't bother making any optimizations, however minor" (my computer's hardware dates back to 2012-14 and a modern system would be at least 2-3x faster in every aspect, even single-thread performance, which has increased the least), leading to "Wirth's Law" (software demands increase as fast or faster than hardware capabilities).
Also, nothing is more insane than the launcher itself, which is literally 4 times the size of the entire game, even larger if you include all its files (besides launcher.dll)!
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?