Memory use myths

Customization software is not resource intensive

Sunday, June 5, 2005 by Frogboy | Discussion: OS Customization

I'm not sure where the myth began. But somewhere down the line, a false belief has turned into pseudo-fact amongst some people that customization software uses a lot of memory.  That's never been the case. Not even in the beginning.

At the dawn of Windows customization, software had to run on Windows 95 which only had 128K (that's kilobytes) of GDI resources. Customization software ate up a lot of those GDI resources since they were reserved for the user interface.  But even in 1995, 16K of memory was trivial. It's just that early versions of Windows were so limited in their GDI resources that it was a problem.

But Windows 2000 and Windows XP have never had any such problem.  And yet, we still see some uninformed, but vocal, user claim that <Program X> is "bloated" and uses a "ton" of memory.  Those people come in two forms:  The guy who really has no idea what he's talking about and the guy who thinks 10 megabytes of memory is a "ton" of memory.

The former guy is annoying because he matches his ignorance with his prolific posting.  The latter guy makes you wonder if their source of income is mom's allowance or something.  I can buy a 256 meg stick of memory for my PC for around $20. 

So let's get this out of the way: Desktop customization programs do NOT use much memory.

Here's WindowBlinds wbload.exe process use:

That's 576K.

Here's DesktopX:

That's only a couple megabytes of memory and it's running a useful object in this instance.

I could go on through a variety of programs both made by Stardock and made by third parties. None of them are "memory hogs".  You can certainly load up enough stuff with something like DesktopX to make it use a ton of memory.  Graphics, animation, etc. has to be stored somewhere.  But that's not the desktop customization's fault any more than it's Photoshop's fault if the user loaded a gigabyte sized image.

So next time someone tries to claim that some desktop customization program is "bloated" or something, point them here.

94 Reply 98 Referrals
First Previous Page 5 of 5 Next Last
Chuckeye
Reply #81 Sunday, November 11, 2007 10:01 AM
Does anyone actually know how to reduce the memory usage of iconX or is that just what I get? Seriously.
Kudos to the real skinners out there, how do you find the time?
Oh yeah I'm not interested in memos, dead horses or underpant comparisons ,no disrespect
that probably makes me a noob or something, I know.Maybe even a retro, oldskool noob
C'mon hit me, I'm ready to accept that 130,000k plus is my own doing. Is it due to the amount on the desktop at any given moment or something, or is that stoopid talk?
Yes I'm not a programmer.

HG_Eliminator
Reply #82 Sunday, November 11, 2007 10:04 AM
I would say that its not typical IconX usage and would wait til a SD member replys as this is the weekend and they are off...

Fuzzy Logic
Reply #83 Sunday, November 11, 2007 10:56 AM
I would say IconX has a memory leak. Mine was at 8Mb at 11:00 today, At 12:30 it was 16Mb. Now, at nearly 16:00 it's 48Mb...

Astyanax
Reply #84 Sunday, November 11, 2007 11:22 AM
Mine uses a bit more than 500kb of memory. Granted I don't really care cause ive got lots of ram... (im guessing wbvista.exe = wbload.exe for xp)

PurrBall
Reply #85 Sunday, November 11, 2007 11:32 AM

Mine uses a bit more than 500kb of memory. Granted I don't really care cause ive got lots of ram... (im guessing wbvista.exe = wbload.exe for xp)



Mine's at 1,104 K, but I'm on 32-bit not 64-bit like you.

I also have a VistaSrv "WindowBlinds Service" process taking up 672 K.

theAVMAN
Reply #86 Sunday, November 11, 2007 12:48 PM
Not quite sure I understand this one but

vStyler
Reply #87 Sunday, November 11, 2007 1:02 PM
Not quite sure I understand this one but


It means its using 60k Harley   

theAVMAN
Reply #88 Sunday, November 11, 2007 1:16 PM

It means its using 60k Harley


John ,I know , but does that not seem quite low to you!

scorpNZ
Reply #89 Sunday, November 11, 2007 1:19 PM
It's not a RAM problem that people suffer & is easily understandable as to why some not so informed people would come to the conclusion that customization software affects performance, on the contrary it has EVERYTHING to do with graphic card power,i should know i experianced it on my own machine that had a 32mb intergrated with 1gb of RAM & more than enough harrdrive space & speed running xp,as an example most blinds would affect say start menu mosue over load speed to get too the all programs list it generally will lag (it's possible that if tweakui were operating then said menu may appear sooner if slider was used to decrease the pause time)however unloading wb would sort it out or by using a minimal blind like liquid 1.1,OD & cxp did'nt appear to affect anything that i can remember,ip did'nt seem to affect anything but adding winfx forget it,as for iconx or widgets i can't comment as i never used to use them,adding a AGP 256 G card fixed any so called performance issues which i assume anyone complaining about memory hogging customization software is saying is in actual affect mistaken graphical card issues for RAM.

Chuckeye
Reply #90 Sunday, November 11, 2007 5:50 PM
Thanx peoples, I am still looking at this,BTW here are some specs they could be better but will have to do for now.
Thanx scorpy, yeah I am totally NOT informed and I'm not looking to blame anyone for this memory issue, it is a weird one though from my myopic POV
Here's a GREEN wallpaper I made - I call it "goblin" feel free to use it, sorry it's not widescreen.WWW Link
[/link]

scorpNZ
Reply #91 Sunday, November 11, 2007 6:30 PM
Chuckeye you watch far too many re-runs of kojak

verdy_p
Reply #92 Wednesday, February 20, 2008 12:21 AM
Is it really needed to inject the code (not dramatic, code is shared by default) but also all the skin data and rederung objects ni all processes for rendering styled windows components? y opinion is that it just need to inject the basic interface that allows interacting correctly with the application, and for the rest the code can be a simple proxy client exchanging data with another process that effectively makes the actual rendering on screen; this just requires sharing the GDI window handles and making their surface or part of their surface accessible to the other process. The issue could be that there would be loss of performance coming from the need synchronization if the separate rendering process is single threaded and uses a serialization queue. However, the rendering process could have several shared worker threads for actually making the rendering. Note that not everything requires rendering in a separate proces, there are simple thnigs that can use shared atoms for things like suctom brushes, and there are lot of things that require just plain brushes for renderng retangles, text... This should not require synchronization in the renderer as this could still be returned to the proxy client as a list of GDI actions to perform for the rendering (think abuot the possibility of Windows Meta File formats for sending instructions to the client proxy). Also, an application can have many windows, but all of them are in the same virtual memory space: there should be a single thread for the whole application to perform the rendering and implement the proxy client. The serialization will be limited by using a process owned queue: this is the role of the windows message loop. Data sharing is really something to consider. Most of the time it's not really useful to maintain separate state varaible for each window used by an application (including the window created by GUI components) and a "light" window can fully emulate the function. This won't affect other processes or the Explorer process or the Desktop that are running in their own environment. The real issue is: can we figure out a system to use data sharing with a maximum of concurrent threads, and create a GUI renderer worker thread only when there's too much contention on the shared data? Generally the limitation is impossible to predict in code, without looking at the possibility of the display driver and hardware, that also implements its own rendering queues... Code sharing is a non-issue. Not using data sharing is the real issue, because it will increase the "working set" and so it will flush out the memory cache (in processors) or pages to disks, and the pages for code coudl be affected, or the CPU will need to add cycles to reread the missing memory in cache. Note that most memory needed should be allocated for the GPU, not the CPU. Beware about the unmonitored use of GPU ressources: if the GPU is overloadedn, the CPU will need to wait and this wil block the processes, that may appear idle: so even if the CPU usage is low, it does not mean that the application is running well, as the applications (and the skins renderer) may be blocked by GPU ressources becoming full, and then the appliation queue will also become full, taking lot of memory for its queues. Optimizing is not something as trivial as you think, and even your performance monitoring tool may be lying: please consider monitoring also the GPU resources!

Philly0381
Reply #93 Wednesday, February 20, 2008 12:31 AM
Wow, way to hard to read. You may even had made some valid points. Try using control Ctrl m the next time to put in some breaks for paragraphs or to establish points of discussion. Not trying to an ahole, just offering some advice.  

Da M4n
Reply #94 Sunday, July 27, 2008 7:57 AM
My objectdock takes up around 4000K and when its being used, around 8000K

Please login to comment and/or vote for this skin.

Welcome Guest! Please take the time to register with us.
There are many great features available to you once you register, including:

  • Richer content, access to many features that are disabled for guests like commenting on the forums and downloading skins.
  • Access to a great community, with a massive database of many, many areas of interest.
  • Access to contests & subscription offers like exclusive emails.
  • It's simple, and FREE!
Login
First Previous Page 5 of 5 Next Last

Home | About | Privacy | Upload Guidelines | Terms of Service | Help
Copyright © Stardock Corporation. All Rights Reserved.


web-wc01