NotHereToPlayGames

That's basically what I have been seeing so far. All I can speak for is "my" computers and the trade-off effect, the "law of unintended consequences". Lowering RAM consumption from 780 - 855 MB range all the way down to 222 MB is truly awesome, make no mistake. BUT on "my" computer, it comes at the cost of it taking three times as long to launch. I'm too impatient to wait "that long" for my web browser to launch - especially considering I "have" that 780 - 855 MB "to spare". The best trade-off I'm finding is to UXP chrome.dll. While this was introduced into the discussion with the innuendo of REMOVING it on the loader, our best balance seems to be to NOT "rebase" chrome.dll and KEEP the loader UXP-compressed but then ALSO UXP-compress the un-rebased chrome.dll. edit - correction, UXP'ing chrome.dll does reduce FIRST LAUNCH after hibernate/full-shutdown, but it increases consecutive launches more then it reduces that first launch.

Did you go this route because wow64.dll always sits in the same region?

I should be pulling this from my x86, but for reference and learning-curve - is this what I should be looking for? Basically, rebase chrome.dll to avoid the 57,664 kB "free" region caused by using default 0x10000000?

Is it safe to assume that I can rebase chrome.dll for x86 then just let my x64 files fall where they want in RAM? It seems my x64 is already doing that since my chrome.dll made it to default 0x10000000 - I have not done any of these checks on x86 yet. When I carried the rebased .dll from my primary computer (x64) to my secondary and had to wait 14 seconds for 360Chrome to launch, I basically stopped right there so far.

@UCyborg - not sure I follow. Rebasing is new to me. This is what Process Hacker is showing -

Thus far, I'm kind of "mixed" on rebasing chrome.dll. I believe that we have to look at the entire picture and not base "everything" off of reducing RAM consumption. I've seen people jump up-and-down with ecstatic exuberation over saving a mere 3 MB of RAM - I don't understand that, at all, to be honest. Make no mistake, RAM consumption is cut drastically when we "rebase" chrome.dll. BUT it also comes at a COST. On my Intel Core2 Quad Q6700, my first launch coming out of hibernate or full-shutdown increased from 4 to 6 seconds (already too high but inline with Mypal, NM, St, and BNav!) to over 14 seconds (simply unacceptable!).

Back home from travels. Very limited testing thus far, but I cannot seem to be able to isolate any system gain or system degradation with comparing compressed loader to uncompressed loader. Only tested on x64 tonight, will revisit on another low-end x86 within the next day or two. Reminder that UPX (and PE) is an "in-place" decompression. UPX (and PE) is not like .NET assembly compression where the file is decompressed and that decompressed file is used "instead of" the compressed file. For UPX (and PE), the COMPRESSED file is being used DIRECTLY by the OS. It isn't decompressed on-the-fly and the decompressed exists side-by-side with the compressed and the OS uses the decompressed instead. Rather, the OS is using the COMPRESSED file DIRECTLY.

Agreed! I also use Actual Window Manager and have noticed this being a possible culprit for why the VERY FIRST launch of 360Chrome coming out of HIBERNATE or FULL SHUTDOWN takes a lot longer then later launches.

From what I am seeing with limited testing only on the cheap laptop that I travel with, I'm seeing it a less strain on CPU Surge to keep the loader COMPRESSED. I'll have to revisit when I can test on a couple of different PCs.

I have not looked into uncompressing it. Do we know if we can uncompress it? I personally DO use the loader because I do not want the registry entries "left behind" when I exit. I run too many different versions here and there and want the registry free of "left behind" entries when I switch between versions. I do run my own "loader" but it runs the "original" loader and then does certain items after the "original" loader is no longer running.

I have zero plans to do anything with the loader. I personally use it and see no issues with it, but I also have my own loader for experimentation (which I do not foresee going public with). If we screencap'd DNS entries or network traffic being conducted by the loader, that would be one thing. But to label it "suspicious" for NO DOCUMENTED REASON WHATSOEVER is not really worth "losing sleep over".

Agreed. I cannot investigate for a few days due to Holiday travels but my hopes is that a rebase of other .dll's will resolve first-run crashes on multi-monitor systems. I don't recall offhand, but I don't think the libglesv2.dll is "required", nor is the "swiftshader" folder - but again, some multi-monitor systems crash without these.

Yep, sure will. This truly is an AWESOME find!

This rebasing is VERY exciting news! Can't thank the "team" enough! I can't test until back home, but I'm starting to think that the rebase is why my multi-monitor setup at home crashes first launch and first launch only if I remove the Vulkan .dll's. Would also prove interesting to compare rebased 1030 with rebased 2022.

For my own compare/contrast learning curve, what was the original .dll that you rebased?

Awesome! I'm on the road traveling for Holiday. I'll do some experimenting with all this new info. Many thanks for this thread finally returning to a high degree of USEFULLNESS.

I discredited this in the past because I saw no gain in x64, but there is a RAM-savings in x86 of roughly 115MB to 120MB if you disable "site isolation" via chrome://flags. edit - with site isolation disabled, my build 2022 at launch but only the empty tab sits at roughly 514MB. but my build 1030 sits only at 382MB. disregard, almost forgot - 1030 crashes on my multi-monitor x64 if i remove vulkan .dll's so i added them back in with 2022. even though i don't even have a vulkan graphics card.

Agreed. Interesting! Yes, very likely. Unsure how to track that down.

I'm still starting to think it's not Hyper-Threading. Maybe graphics-related? ???

I'm starting to think that it is not Hyper-Threading and it is also not x64. ???

Neither do I.

Same here. It's always kind of funny that whenever somebody says "proxy", they pretty much always assume "shady surfing" or trying to "hide" or log into websites that they are otherwise blocked or banned.

My Win10 x64 with no hyper-threading i5-6300U: Of course that's Win10 and not XP. Could be several MONTHS before I could spend the time to put XP on my i5-6300U laptop.

You "kind of" do. AMD does NOT support Hyper-Threading and 360Chrome on your non-Hyper-Threading Vista x64 is under 200 MB, if I remember correctly without scrolling back a few pages. So does this elliminate Hyper-Threading as a variable ???