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

[msfntor]

1 hour ago, mixit said:

The columns are Private bytes/Peak private bytes/Virtual size/Peak virtual size per Process Hacker

Why you not consider "Working set"? That's memory usage.

[NotHereToPlayGames]

2 hours ago, UCyborg said:

Yes, but it's almost 800 MB on the same machine on XP x64 SP2.

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

 

???

[mixit]

9 minutes ago, msfntor said:

Why you not consider "Working set"? That's memory usage.

Possibly because I have that column set up further back so I'd have to scroll to see it and "out of sight, out of mind".

[msfntor]

2 minutes ago, mixit said:

Possibly because I have that column set up further back so I'd have to scroll to see it and "out of sight, out of mind".

Deplace it on the first column, like me, enlarge the window.

Edited December 22, 2022 by msfntor

[AstroSkipper]

17 hours ago, IXOYE said:

Hi

here is my system with chrome 13.5.2022 in active use with only Ublock origin

 

Hello @IXOYE! Could you please be so kind to perform your test once again with Hyper-Threading disabled? If the values did not change significantly without activated Hyper-Threading, this would be a clear indication for disproving my theory that this feature is responsible for lower memory consumption. Thanks in advance! 

Edited December 22, 2022 by AstroSkipper

[NotHereToPlayGames]

7 hours ago, gerwin said:

Oh look!

This system is quite similar to the main i5-3550 above, also a GigaByte 6-series motherboard. Except it has an i3-3220 with 2 real cores and 2 HT. It has nVidia GT 710 graphics instead of AMD Radeon 7750.

Now I just went into the BIOS and disabled the two HyperThreading cores. Run the test again: Taskmanager shows now 2 threads instead of 4, and the 360chrome memory allocation is quite the same (=low) so I did not bother to make a screen shot again.

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

 

???

[AstroSkipper]

3 hours ago, mixit said:

FWIW, this 360 memory usage issue doesn't seem to depend (much) on hardware or 32/64-bit XP.

This is how it behaves on two of my systems (deliberately not giving their specs).
The columns are Private bytes/Peak private bytes/Virtual size/Peak virtual size per Process Hacker

#1 XP x64 safe mode:
 40.78 MB,  43.53 MB, 298.88 MB, 320.48 MB
 22.66 MB,  22.73 MB, 237.16 MB, 240.91 MB
 12    MB,   12.9 MB, 212.93 MB, 215.56 MB
 14.72 MB,  15.12 MB, 219.1  MB, 220.35 MB
 18.53 MB,  20.85 MB, 233.04 MB, 233.04 MB
 27.84 MB,  35.43 MB, 243.05 MB, 252.11 MB
-----------------------------------------
136.53 MB            1444.16 MB

#1 XP x64 normal:
144.02 MB, 149.41 MB, 337.77 MB, 359.34 MB
124.61 MB, 124.71 MB, 247.54 MB, 255.79 MB
118.21 MB, 120.66 MB, 240.08 MB, 243.83 MB
116.56 MB, 119.95 MB, 222.2  MB, 223.45 MB
121.02 MB, 123.12 MB, 233.58 MB, 234.83 MB
130.8  MB, 140.68 MB, 248.53 MB, 255.81 MB
-----------------------------------------
755.22 MB            1529.7  MB

#1 XP x64 fresh install:
(saved partition, NO drivers/software that aren't from the official CD)
 38.84 MB,  43.11 MB, 305.51 MB, 325.8  MB
 22.96 MB,  23.04 MB, 233.99 MB, 237.77 MB
 12.43 MB,  13.38 MB, 212.94 MB, 215.88 MB
 15.06 MB,  15.47 MB, 217.15 MB, 218.4  MB
 19    MB,  21.1  MB, 229.52 MB, 229.52 MB
 28.12 MB,  34.22 MB, 252.29 MB, 261.35 MB
-----------------------------------------
136.41 MB            1451.4  MB



#2 XP x86 safe mode:
 33.31 MB,  35.57 MB, 279.27 MB, 291.3  MB
 19.54 MB,  19.58 MB, 207.03 MB, 210.56 MB
  9.03 MB,  10.02 MB, 190.2  MB, 191.7  MB
 12.9  MB,  14.09 MB, 716.5  MB, 717.5  MB
 16.59 MB,  20.57 MB, 723.69 MB, 726.38 MB
 25.76 MB,  34.08 MB, 741.77 MB, 744.52 MB
-----------------------------------------
117.13 MB            2858.46 MB

#2 XP x86 normal:
137.5  MB, 140.19 MB, 290.51 MB, 310.59 MB
121.35 MB, 121.39 MB, 211.94 MB, 217.47 MB
113.72 MB, 118.63 MB, 207.76 MB, 209.26 MB
115.16 MB, 118.66 MB, 708.92 MB, 709.92 MB
119.27 MB, 122.78 MB, 729.05 MB, 731.98 MB
127.8  MB, 135.48 MB, 741.06 MB, 745.31 MB
-----------------------------------------
734.8  MB            2889.24 MB

It's interesting that virtual sizes are quite close (per OS/HW) even when RAM usage differs greatly between safe mode and "normal" boot. But clearly something has happened between the fresh install and my current configuration to cause this difference.

Edit: The 360 profile used was exactly the same, copied from one system to the other.

Very interesting is the difference between #2 XP x86 safe mode and #2 XP x86 normal with regard to the values of the Private bytes column. In normal mode, you have similar values such as @NotHereToPlayGames and me, but in safe mode, much lower values such as many others here.  At the next opportunity, I will also test 360Chrome in safe mode. 
And the difference between #1 XP x64 normal and #1 XP x64 fresh install (saved partition, NO drivers/software that aren't from the official CD) with regard to the values of the Private bytes column makes me suspect that certain drivers, e.g. for memory management, could be responsible. 

Edited December 22, 2022 by AstroSkipper

[IXOYE]

Hi

1 hour ago, AstroSkipper said:

Hello @IXOYE! Could you please be so kind to perform your test once again with Hyper-Threading disabled? If the values did not change significantly without activated Hyper-Threading, this would be a clear indication for disproving my theory that this feature is responsible for lower memory consumption. Thanks in advance! 

Chrome 13.5.2022 with active "Ublock origin" plugin

Edited December 22, 2022 by IXOYE

[AstroSkipper]

10 minutes ago, IXOYE said:

Hi

Chrome 13.5.2022 with active "Ublock origin" plugin

Thanks a lot! This is a clear indication for disproving my theory that Hyper-Threading is responsible for lower memory consumption. Hyper-threading is not the culprit. 

[XPerceniol]

10 hours ago, NotHereToPlayGames said:

 

Q6700 does NOT support Intel Hyper-Threading.

 

Neither does my T7500.

My T7500 has 360Chrome at:

What software do you like me to use to test to values on my computer? I keep seeing it but don't know.

Anyway. opening a black window from first run and doing nothing.

 

Edited December 22, 2022 by XPerceniol

[NotHereToPlayGames]

41 minutes ago, AstroSkipper said:

Thanks a lot! This is a clear indication for disproving my theory that Hyper-Threading is responsible for lower memory consumption. Hyper-threading is not the culprit. 

Agreed.

1 hour ago, AstroSkipper said:

makes me suspect that certain drivers, e.g. for memory management, could be responsible. 

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

[NotHereToPlayGames]

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.

Edited December 22, 2022 by NotHereToPlayGames

[mixit]

I think this "one empty tab at startup" metric may actually not be all that useful, because if you open up a bunch of of additional tabs to fill out all available memory (for example pile up Youtube videos) and then close them all, the initiall processes' working sets[1] have gone down to the lower bounds reported here and appear to stay there afterwards, even though their private bytes values stay at the upper bounds. YMMV, but that's what I saw just now - even working with settings pages and dev tools it that tab didn't make them go up again.

Edit: I'm pretty sure though that this particular metric isn't the only reason @AstroSkipper says he can't use 360 on a low spec system.

[1]Thanks @msfntor for the reminder. My XP x64 daily driver has 32 GB RAM, so these two values tend to stay pretty close, making me forget about the difference.

Edited December 22, 2022 by mixit

[AstroSkipper]

47 minutes ago, NotHereToPlayGames said:

1 hour ago, AstroSkipper said:

Thanks a lot! This is a clear indication for disproving my theory that Hyper-Threading is responsible for lower memory consumption. Hyper-threading is not the culprit. 

Agreed.

1 hour ago, AstroSkipper said:

makes me suspect that certain drivers, e.g. for memory management, could be responsible. 

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

The drivers for memory management are usually part of the chipset drivers. We have to look at them if they are the causer. 

Edited December 22, 2022 by AstroSkipper

[XPerceniol]

Hi, its me, the one you love to hate (or is it ... hate to love)  ... haha

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

Thank you.

Edited December 22, 2022 by XPerceniol