Tue, 01 Dec 2009 16:48:34 -0500, Steven Schveighoffer wrote:

> On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha <dsimcha@yahoo.com> wrote:
> 
>> == Quote from Steven Schveighoffer (schveiguy@yahoo.com)'s article
>>> If the compiler could somehow
>>> optimize out all instances of the template function to reduce bloat, I
>>> think that would make it a little less annoying.
>>
>> What is the sudden obsession with code bloat here lately?  Check out
>> this StackOverflow question that I posed a few weeks ago.  If anyone
>> has a decent
>> answer to it, I'd love to hear it.
> 
> If I'm writing template code effectively as a "macro" meaning "call this virtual method", then there is no point in having template code whatsoever.
> 
> If I'm forced to write it because the compiler only will call a template, then I would like for the compiler to optimize out its "mistake".  Then I have no problem with it, because the net effect on the binary performance and size should be zero.  Even if I have to annotate the function to force it, that is fine with me.
> 
> Larger programs take more memory to run, and longer to load.  Not that my D programs need to squeeze every ounce of power out of the system, but I think nowadays there's too little emphasis on executable size optimization (or even memory consumption).
> 
> an ancecdote on bloatage:  I once had a driver for XP for my wireless USB network adapter that put an icon on the task tray, consuming roughly 10MB of memory.  Yep, to put an icon on the task tray, it needed 10MB. Just in case I ever wanted to click on that icon to set up my wireless network (which I would never do because once it's set up, I'm done).  As a bonus, every week or so, some kind of memory leak would trigger, and it would consume about 200MB of memory before my system started thrashing and I had to kill the icon.  I tried to disable it and use Windows to configure my wireless card, and then it used 10MB to put a *grayed out icon* in the tray (which would continue the bonus plan).  I finally had to hunt down the offending executable and rename it to prevent it from starting.  And guess what?  the wireless adapter worked flawlessly.  It's shit like this that pisses me off when people say "oh, bloat is a think of the past, you get soo much memory and cpu now adays, you don't even notice it."  All those little 10MB programs add up pretty quickly.

If it leaks 200 MB per day, people can already run it for a month on a typical home PC before the machine runs out of physical memory (assuming 8GB physical RAM like most of my friends have these days on their $500-600 systems).

A typical user reboots every day so a program can freely leak at least 7 gigs per day, (during a 8h work day) that's 15 MB per minute or 250 kB per second. According to Moore's law the leak rate can grow exponentially. So in 2013 your typical taskbar apps leak at least one megabyte per second and most of users are still happy. With a RAM upgrade they can use apps that leak 4+ MB per second. As users tend to restart programs when the system starts running slowly, the shorter uptime of apps means that they can leak a lot more.

On Wed, 02 Dec 2009 01:36:54 -0500, retard <re@tard.com.invalid> wrote:

> If it leaks 200 MB per day, people can already run it for a month on a
> typical home PC before the machine runs out of physical memory (assuming
> 8GB physical RAM like most of my friends have these days on their
> $500-600 systems).

Notice I said XP.  this system had 500MB of RAM, it's not a new system.  AFAIK, XP doesn't even *support* more than 4GB of RAM (and I don't think my chipset would support more than 1G).  200MB is probably the most the OS would give it, because I think my typical idle memory usage was 400MB.

Let's just say instead of 200MB, it uses whatever memory was left to consume, ok?

But the memory leak isn't the biggest issue, that is clearly a bug and not a feature.  The problem I have is the 10MB of memory it uses to put an icon on the task tray.  I see loads of these icons all the time on other people's computers, all using up huge chunks of memory so they can instantaneously check for the latest logitech driver for their keyboard (oooh! what new awesome amazing things will my keyboard be able to do with this upgrade!).  It's the computer equivalent to hiring a team of people around you 24/7, and some of those team member's *ONLY* job is to give you a q-tip in case you want it.

And moores law seems to apply to moronic icon developers as well -- the more memory available, the bloatier they make their nifty task tray icons "hey, Windows 7 supports an alpha channel!  let's make the icon [that nobody ever uses] fade in and out!"

> A typical user reboots every day so a program can freely leak at least 7
> gigs per day, (during a 8h work day) that's 15 MB per minute or 250 kB
> per second. According to Moore's law the leak rate can grow
> exponentially. So in 2013 your typical taskbar apps leak at least one
> megabyte per second and most of users are still happy. With a RAM upgrade
> they can use apps that leak 4+ MB per second. As users tend to restart
> programs when the system starts running slowly, the shorter uptime of
> apps means that they can leak a lot more.

I don't know what typical users you know, but the typical users I know do not reboot their computer unless it requires it.  Most of the people I know have installed so much bloatware on their system that it takes 20 minutes to boot their system, so they only reboot when necessary.

Your idea of "x amount of leakage is OK" where x > 0 is exactly the developer mindset I was talking about.

-Steve

Wed, 02 Dec 2009 13:15:33 -0500, Steven Schveighoffer wrote:

> I don't know what typical users you know, but the typical users I know do not reboot their computer unless it requires it.  Most of the people I know have installed so much bloatware on their system that it takes 20 minutes to boot their system, so they only reboot when necessary.

Ok, if they accept those long boot times, you can waste even more memory since they would probably accept disk cache trashing, too. Nowadays laptops have 640 GB hard drives, so basically a taskbar applet could easily use 100 GB of virtual RAM without the stupid user noticing anything.

> Your idea of "x amount of leakage is OK" where x > 0 is exactly the developer mindset I was talking about.

It's not my idea :D I guess even if I was badly drunk, I couldn't make my code leak as much as those taskbar application developers do. I don't encourage writing bloaty crap applications. It's just the general trend. Applications get larger and slower. Wirth's law.

If I recall correctly, my old postscript printer only needed a ppd driver file (< 100 kB). Nowadays even the cheapest printers with very modest features come with 500+ megabytes of "drivers". Since there is no good package manager on Windows, each vendor implements their own, poorly. The high end printers still use light weight drivers. What does this tell?

If the printer costs $40, a webcam $15, and a network card $5..10, how can you expect extremely high quality drivers? They hire those worst off- shore coders to do the job, the cheapest artists draw the 16 color installer backgrounds (saved in 24-bit BMP format of course to waste more space) etc.