[aklug] Re: A developer's take on system resource consumption

From: Shane R. Spencer <shane@bogomip.com>
Date: Tue Jun 14 2011 - 08:52:03 AKDT

I use the "If you love it, let it go." memory allocation philosophy. I'm currently diving
into ObjC to get some iOS related tasks done and I am completely amazed at how poorly all
of the example code I'm running into deals with memory management and how much absolute
cruft is kept in memory. Even if you try to relate it to caching and preloaded for a
faster UI time it's still just a ton of cruft.

In most cases these are all examples of how to do a specific thing, however I've been
reviewing source for other published products that have open source and there too.. I just
don't understand how they can get away with using up so much memory all the time.

I really like seeing stuff like "copy this array to this other array.. then use this
function to filter out objects in the new array". I call that lazy. You still have to
iterate through the list to filter.. just add things as you go. However you won't
immediately run into a memory allocation problem if you can't store the entire result set
if you run the loop in your own code instead of via a library which abstracts that a
little. Sigh.. this is preferred of course - to double your memory footprint for an
object just to filter it and retain the original. Drives me bonkers. Nothing says I have
to work that way but it makes me insane thinking of if preloading and utilizing the cache
is actually better than being a stingy with memory for most cases. For all I know both
work equally well and have the same potential memory footprint - one just meets it sooner
and reduces it later.

That said. There are a lot of "helper" functions in the C and C++ world that attempt to
take care of everything on your behalf now that the day and age of reasonably high
resources is here. When you're building a gigantic project it's much nicer to decide on
or build a framework that the entire project can then use in order to keep things uniform.
 Optimizations to the framework are gambled as a speed boost for most situations calling
that function. You basically build a framework that not only educates your fellow
programmers but also communicates the projects code style without a bunch of horribly
expensive meetings. (cookies can get expensive for thousands of people).

I can't blame firefox for being slow and memory hoggish because of that, it's surely
difficult. They had to organize a ton of people into lots of little areas and everybody
had to create their own solution that met up to the expectations of everybody else and
interfaced cleanly with the core product.

More power to them. It's obscenely difficult making a product that offers an interpreted
language facility that works just as "well" as the competition and place memory management
rules in place without ruining the developer appeal.

- Shane
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue Jun 14 08:52:13 2011

This archive was generated by hypermail 2.1.8 : Tue Jun 14 2011 - 08:52:14 AKDT