[slhk]

Tihiy, on May 16 2009, 11:22 PM, said:

Quote

How about web browsers?

IE - based ones, for sure. Unlikely for others. Is there browsing scenario which eats a lot of USER (except opening lots and lots of pages)?

Firefox3 crashed easily after browsing alibaba.com for a while

Shall try IE when your new technology is launched, though I still prefer to use non-IE based browser

[dencorso]

Tihiy, on May 15 2009, 06:58 PM, said:

I'm pleased to announce that future Revolutions Pack 9 version will include technology which will greatly reduce USER resource usage in common scenarios. After your reports and my research i found a big hole in USER heap which i'm able to plug.

Way to go, Tihiy! I shall test it as soon as you release it!

[eidenk]

Hi, as i mentioned to dencorso by PM some time ago, I could not install RP9 properly because it turned out my registry was damaged since a couple of months.

Since this has been repaired I have now been using minimal install of RP9 since a few weeks and it seems stable enough here. There seem to be a little benefit with the resource usage but they end up getting depleted anyway. Perhaps your new fix will make this better.

Anyway, the point of this post is asking you tihiy whether there is a possibility you could release this resource optimizer as a standalone dll who could be installed without installing the rest of RP9.

I am guessing you got into doing such an optimizer to offset the cost of RP9 in resources and I am imagining that if RP9 wasn't there along the optimizer I would see an increase in free resource on fresh boot of perhaps 10% instead of 1 or 2%.

[Drugwash]

Tihiy, on May 16 2009, 06:22 PM, said:

Quote

How about web browsers?

IE - based ones, for sure. Unlikely for others. Is there browsing scenario which eats a lot of USER (except opening lots and lots of pages)?

SlimBrowser eats about 30-40% of resources, sometimes more. It does release most of them (save for 2-3% maybe) but only on exit, not on page close.
I could test your "baby" here since SB is open about all the time.

[Tihiy]

eidenk, unless you use window skin, there is no differences in resource usage - since i know how to not use resources. You may want to cut RP9.1 into bare-bone by using only RP8.dll (deleting shl8.dll, uberhack.exe), but note, i'm about to change component dependencies.

[eidenk]

Thanks for the headup Tihiy. I was only wondering because I saw all the stuff there is in the ctrl-alt-del panel, the quite big bitmap notably, but if you say it's all optimized, no worries. I'll try without the other dlls and see how it fares. Looking forward trying the new RP9 with the new User optimizations.

[M()zart]

Tihiy, on Mar 28 2009, 12:58 PM, said:

So is it worth it? Tell me scenarios you lack resources in.

May be its a bit too late for this but I tell you my two scenarios.

The first one is with SolSuite 2008. It is still compatible with Windows 98 (and 2009 also), but it eats VERY many GDI resources, more than 30% - 35 or even 50, though it releases them when closed. And I often browse with firefox and playing SolSuite simultaneously, because with my dial-up and disconnects every 2 minutes browsing is for patient people . And I sometimes lack GDI resources.

The other scenario is playing Worms 2 portable. The game eats more GDI resources each time I start new match and does not release them, even after closing it, even with your RP 9.1. So if I try to play more than 3 - 4 matches without rebooting Windows crashes.

Couple of times I also had to press reset due to insufficient USER resources, even your kernel task manager was unable to help, but I cannot give you typical scenario. It seems that it was long uptime, active browsing with firefox and/or Opera.

My Evolve screensaver also eats 1-3 % of resources each time it works and does not release them, but it is not so big loss. Other apps behave well and release their resources, may be because of your RP.

[dencorso]

In posts #2, 3 and 4 I had reproduced, as quotations, the now lost, original resources thread, from what I had saved myself. All posts between Oct 19 2007 and Nov 20 2007 were then lost. Now, thanks to RetroOS, who sent me a copy of the part I was missing, I have been able to complete the recovery of the original thread. So, now, the quoted thread in posts #2, 3 and 4 is complete. Thanks a whole lot, RetroOS! You do rock!

[Tihiy]

Not fair to spoil exectations, but i'm here again with some news.

New USER salvation is delayed due to my work on KernelEx 4 (finally) as well as other busy things.

The news, i've figured out how to theoretically implement GDI heap expander without breaking compatibility, performance and memory usage. This includes a lot of things to hax: global memory manager, local heap handle manager and GDI insides, but seems possible unless I bump into hard compatibility problems.

But theoretically, it can be very-very promising; i won't spoil numbers.

Or did rloew already implemented one?

[dencorso]

Way to go, Tihiy!!!

[eidenk]

Tihiy, on May 31 2009, 02:59 PM, said:

Not fair to spoil exectations, but i'm here again with some news.

New USER salvation is delayed due to my work on KernelEx 4 (finally) as well as other busy things.

The news, i've figured out how to theoretically implement GDI heap expander without breaking compatibility, performance and memory usage. This includes a lot of things to hax: global memory manager, local heap handle manager and GDI insides, but seems possible unless I bump into hard compatibility problems.

But theoretically, it can be very-very promising; i won't spoil numbers.

Or did rloew already implemented one?

That's all great news Tihiy.

I might be wrong but I don't think rloew is into an heap expander at all as he's mentioned ongoing research into 512 MB graphic card and multiprocessor support and did not answer a question aboit a heap expander I made to him sometimes ago.

[rloew]

eidenk, on Jun 1 2009, 05:18 AM, said:

Tihiy, on May 31 2009, 02:59 PM, said:

Not fair to spoil exectations, but i'm here again with some news.

New USER salvation is delayed due to my work on KernelEx 4 (finally) as well as other busy things.

The news, i've figured out how to theoretically implement GDI heap expander without breaking compatibility, performance and memory usage. This includes a lot of things to hax: global memory manager, local heap handle manager and GDI insides, but seems possible unless I bump into hard compatibility problems.

But theoretically, it can be very-very promising; i won't spoil numbers.

Or did rloew already implemented one?

That's all great news Tihiy.

I might be wrong but I don't think rloew is into an heap expander at all as he's mentioned ongoing research into 512 MB graphic card and multiprocessor support and did not answer a question aboit a heap expander I made to him sometimes ago.

I haven't been working on the Resource problem in a while. Early analysis showed that there is no central block of code that handles them. It appears that many if not all particular Resources are coded individually. I haven't worked with 16-bIT Thunks, so it would take me a lot longer to identify and Patch all of the code that handles Resources. Even Patching one Resource at a time would not be easy since I don't know an easy way of determining all of the pathways to a given Resource.

I have only been looking at the 512MB Graphics Card issue for a matter of days. So far only one person has contacted me about testing.
I have thought about making use of Multiple Pocessors or Cores but only under Program Control, not the OS. I have not done the research or written any code yet.

[Tihiy]

I'm back with news, and news are not bad: a functional alpha version of GDI extender was created.

My theory of decoupling handles from objects seems applicable (although there were lot of problems to make friends with GDI).
For now, only one type of object is extended: DIB bitmap. DIB bitmaps are actively used in a lot of programs (unfortunately, most leaky programs like Foxs*** pdf reader, your card game, that VB tool are likely to use DDB bitmaps) and are very heavy (2 global memory objects + selector array). Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9. My favorite 3xImgBurn test showed twice resource usage drop, allowing me to open 6xImgBurn copies (with user heap extender alpha enabled too).

Performance hit is negligible - 5% max in tests on my VM.

So, wanna wanna wanna? I'm planning to include both technologies in Revolutions Pack 10 (with completely rewritten core).
Beta testing may be possible, but i'm not promising any time / deadline.

This post has been edited by Tihiy: 04 July 2009 - 08:49 AM

[Joseph_sw]

Tihiy, on Jul 4 2009, 09:39 PM, said:

I'm back with news, and news are not bad: a functional alpha version of GDI extender was created.

My theory of decoupling handles from objects seems applicable (although there were lot of problems to make friends with GDI).
For now, only one type of object is extended: DIB bitmap. DIB bitmaps are actively used in a lot of programs (unfortunately, most leaky programs like Foxs*** pdf reader, your card game, that VB tool are likely to use DDB bitmaps) and are very heavy (2 global memory objects + selector array). Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9. My favorite 3xImgBurn test showed twice resource usage drop, allowing me to open 6xImgBurn copies (with user heap extender alpha enabled too).

awesome, with this image not displaying in browser could be remedied somewhat.

the problem was like this:
browser just showing blank white image yet it said that image has been completely downloaded, but if you looking for image files in cache, you can view it just fine with (dos) image viewer.

'Tihiy' said:

So, wanna wanna wanna?

you bet!

[Tihiy]

Nobody is interested?

Then i'll tell you how to increase GDI 32-bit heap now.
32-bit GDI heap is 2MB by default, that's pretty much; but, GDI actively utilizes this heap for storing small images and discarding DCs there. While it's not that easy to fill this heap, it is possible. With default 2MB heap worst case filling scenario would be ~200 48x48 images or ~5000 DCs (only likely if you're using leaky programs).

So it's good thing to increase GDI 32-bit heap size. It would be required for heap extender to go all-out, too.
Remember, this value is maximum size, not commited-at-once size. Don't ever set it smaller than 2MB.

You can change this value by adding line in win.ini section [windows]

Quote

[windows]
GDIMaxHeapSize=2048

(value in KB)

I would think of values like:
<128MB of RAM: 4096 (4MB)
128-256MB of RAM: 8192 (8MB)
256-512MB of RAM: 16384 (16MB)
>512MB of RAM: 32000 (~32MB, maximum value you can set).

Not likely you often run into this limit, but this knowledge is nice to recall.

[RetroOS]

Tihiy, on Jul 5 2009, 02:39 AM, said:

...
So, wanna wanna wanna?...

I second that! - Yes, yes, yes!
GDI heap extender and User heap extender will be awesome!
RP10 will be some pack indeed!

BTW, nice tip about how to increase the GDI 32-bit heap.

This post has been edited by RetroOS: 05 July 2009 - 04:12 AM

[Drugwash]

Tihiy, you know I'm always interested in testing/using such enhancements. You can count on me for alpha/beta testing at any time. Just use PM for details/links since I'm no longer using instant messaging.

[dencorso]

@Tihiy: Supposedly, you can also go to HKEY_CURRENT_USER/Control Panel/Desktop/ and create the string value USERMaxHeapSize there, to control the max 32-bit USER heap size. While USERMaxHeapSize indeed exists inside USER.EXE, what I always found strange is: (i) why the control for USER is inside the registry, while the one for GDI is at WIN.INI?; (ii) why is it a string and not a DWORD or binary value? (iii) why WIN.INI instead of SYSTEM.INI?
It occurs to me that they may be alternative places, and that using both in the indicated place at the resgistry or both in WIN.INI would work the same, but, if so, why? Moreover, why, before you mentioned it, I'd only found these settings in french sites, which apparently cite one another (this one, for instance)? I know, I know... that's too many questions! But I just wasn't able to resist posing you them since you wrote about GDIMaxHeapSize.
And, yes, yes, yes! You can count on me too to alpha/beta test, whenever you want it.

@Drugwash: Have you given Miranda up? I see you've purged it from your sinature too! What happened?

[Drugwash]

dencorso said:

What happened?

Something as infinite as the universe, as Mr. Albert once said. But it's not worth hijacking this thread.

[slhk]

Tihiy, on Jul 4 2009, 10:39 PM, said:

Applying extender on them allowed to increase best case object count from 1'200 to 12'000! That means you can potentially open 10 times more tabs in Opera 9.

Tihiy, on Jul 5 2009, 06:02 PM, said:

Nobody is interested?

Come on, Tihiy ... We are all waiting for this ...