ArcticFoxie/NotHereToPlayGames -- 360Chrome v13.5.2022 rebuild 3

[AstroSkipper]

5 minutes ago, XPerceniol said:

Hi, its me, the one you love to hate ... haha

Again, what software are you guys using so I can test and help out, please.

Thank you.

Use Process Hacker for checking RAM consumption! Look at my screenshots! And SIV32X or CPU-Z for hardware specs.

Edited December 22, 2022 by AstroSkipper
Update of content

[XPerceniol]

10 minutes ago, AstroSkipper said:

Use Process Hacker for checking RAM consumption! Look at my screenshots! And SIV32X or CPU-Z for hardware specs.

Thank you very much

 

Edited December 22, 2022 by XPerceniol

[AstroSkipper]

22 minutes ago, XPerceniol said:

Thank you very much

 

And your hardware specs? The consumption values without information about the system used are not meaningful. Just add a screenshot of SIV32X with your hardware specs! 

[XPerceniol]

[AstroSkipper]

9 minutes ago, XPerceniol said:

Thanks! This is a 64-Bit computer. Your values are a bit high in two processes of 360Chrome but otherwise similar to the others using 64-Bit CPUs. But more interesting would be values from a 32-Bit computer if you have one. 

[XPerceniol]

Thank you and I'll get those values for you when I get back from my doctors appointment (eye doctor).

But, I'll save you the trouble of concern, on my Dell Dimension 3000single core Pentium 4, 360 V12 and 13 will not even work at all without countless skipping. V11 was the only one and I gave up because of youtube. That computer is my backup and only good for little computing. 

[msfntor]

1 hour ago, XPerceniol said:

Thank you very much

 

@XPerceniol, I see that in your Windows XP x32 Professional v5.01 Build 2600 SP3 (have this same but SP2) - you have only two svchost.exe -that's very good, I always had 3 svchost.exe, but I see 4 these now? One for WIA, then other for many general processes, then other for RPC, then latest - for DCOM launch...total 4 these... hmm

[msfntor]

35 minutes ago, XPerceniol said:

Thank you and I'll get those values for you when I get back from my doctors appointment (eye doctor).

Be careful to touch only clean, disinfected surfaces with your face!

Otherwise you could catch the odd bacteria...

[AstroSkipper]

360Chrome v13.5 build 2022 in safe mode



Same consumption values in safe mode as in normal mode. But I have to mention that the same drivers for memory management were loaded in both modes. Therefore, no further conclusions can be made here, unfortunately.

Edited December 22, 2022 by AstroSkipper

[AstroSkipper]

6 hours ago, NotHereToPlayGames said:

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.

I already did that in 360Chrome v13.5 build 1030 months ago. This version is generally less RAM consuming than 360Chrome v13.5 build 2022. One 360Loader.exe and only four 360Chrome.exe processes with a total of round about 500 MB. That's the lowest value I ever had for 360Chrome 13.5. And I don't know why the version 360Chrome v13.5 build 2022 consumes much more. 

Edited December 22, 2022 by AstroSkipper

[mina7601]

18 hours ago, UCyborg said:

Did you guys just make a bunch of assumptions about me using proxy?

No, I just replied to @XPerceniol's post saying my opinion about proxy servers. I didn't assume what you used.

Edited December 22, 2022 by mina7601

[XPerceniol]

18 hours ago, UCyborg said:

Did you guys just make a bunch of assumptions about me using proxy?

No ... I was replied as if it were discussion about proxies. Everybody has their own reason(s) to need to hide and I make no judgement; either way. 

[UCyborg]

Seems chrome.dll needs to be rebased. It uses the default preferred base address used by MS build tools (which is constant) and is unable to be loaded at its preferred base address on my XP and the DLL itself is huge, so it seems logical if the OS has to duplicate huge chunk of it in every chrome.exe process to be able to fix-up addresses inside, that would be costly in terms of memory.

I did rebasing when I patched old games (at least those I've spent most time working on) that used DLLs, which were small and these games don't spawn multiple processes. Back then I found the tool that chose the address based on the name of the DLL with optional INI file to specify base address and separation (how much apart they should be in the address space). I think the idea is to line up DLLs of your application at higher addresses, preventing conflicts with each other or another system softwares' / utilities' DLLs so OS doesn't have to rebase them at load time. Having them loaded in upper portion of the address space should leave large contiguous space for memory allocations.

Some interesting reading here and here. There's the hint why you don't see the issue on Vista+.

Anyway, here's the tool (libase.zip), it's in the Release subfolder, have both chrome.dll (from Chrome\Application\13.5.2022.0 folder) and libase.exe in the same folder, open CMD, cd to that folder and run:

libase chrome.dll

Copy chrome.dll back, launch the browser and check the memory consumption.

No idea where the tool was originally published and who wrote it, I think it came only in source code form and I wrapped it inside Microsoft Visual C++ 6.0 (another dinosaur) workspace file and compiled it. Microsoft has their own tool in their compiler suite that can also rebase executables and DLLs (reference).

So it's an issue that is easily fixable, but not many people seem to pay attention to such details. Rebasing other browser's DLLs should also save a little bit of memory.

42 minutes ago, mina7601 said:

No! I just replied to @XPerceniol's post saying my opinion about proxy servers. I don't assume what you (or anyone) use.

Just now, XPerceniol said:

No ... I was replied as if it were discussion about proxies. Everybody has their own reason(s) to need to hide and I make no judgement; either way.

Well, I do assume things at times.

Edited December 22, 2022 by UCyborg

[XPerceniol]

26 minutes ago, UCyborg said:

Seems chrome.dll needs to be rebased. It uses the default preferred base address used by MS build tools (which is constant) and is unable to be loaded at its preferred base address on my XP and the DLL itself is huge, so it seems logical if the OS has to duplicate huge chunk of it in every chrome.exe process to be able to fix-up addresses inside, that would be costly in terms of memory.

I did rebasing when I patched old games (at least those I've spent most time working on) that used DLLs, which were small and these games don't spawn multiple processes. Back then I found the tool that chose the address based on the name of the DLL with optional INI file to specify base address and separation (how much apart they should be in the address space). I think the idea is to line up DLLs of your application at higher addresses, preventing conflicts with each other or another system softwares' / utilities' DLLs so OS doesn't have to rebase them at load time. Having them loaded in upper portion of the address space should leave large contiguous space for memory allocations.

Some interesting reading here and here. There's the hint why you don't see the issue on Vista+.

Anyway, here's the tool (libase.zip), it's in the Release subfolder, have both chrome.dll (from Chrome\Application\13.5.2022.0 folder) and libase.exe in the same folder, open CMD, cd to that folder and run:

libase chrome.dll

Copy chrome.dll back, launch the browser and check the memory consumption.

No idea where the tool was originally published and who wrote it, I think it came only in source code form and I wrapped it inside Microsoft Visual C++ 6.0 (another dinosaur) workspace file and compiled it. Microsoft has their own tool in their compiler suite that can also rebase executables and DLLs (reference).

So it's an issue that is easily fixable, but not many people seem to pay attention to such details. Rebasing other browser's DLLs should also save a little bit of memory.

 

This is way over my head :/

[UCyborg]

I can upload my chrome.dll for others to try. It should make the difference in case you currently see chrome.dll in orange in Process Hacker when you open 360chrome.exe and go to Modules tab (should no longer be orange with the old new DLL). At least the chance is very low that it still fails to load at its new address, if it does fail, it'll be orange again (bad!).

Edited December 22, 2022 by UCyborg