Tue, 01 Dec 2009 16:48:34 -0500, Steven Schveighoffer wrote: > On Tue, 01 Dec 2009 16:28:14 -0500, dsimcha <dsim...@yahoo.com> wrote: > >> == Quote from Steven Schveighoffer (schvei...@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.