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

I personally like the option of static lists/hashes/etc where you initialize it in a
single call.

Having the offset, length and type information in an easily scanned fixed length struct
defining the type, offset, and length after presenting an initial object count means
really darn quick access to objects in memory.

From what I understand there are several different methods for dealing with mutable lists
that involve linked lists and storing a mutable object reference. I'd prefer a mutable
object reference even though it requires locking and a larger memory footprint. Linked
lists are fine if you don't mind scanning through memory. If you're using an integrated
linked list library you may not be able to cache information related to elements either.

A coworkerperson was looking for a good reason to use tuple types vs lists in Python. I
guess the best reason was access speed. If you end up having to copy the list and filter
it constantly you're probably better off with a mutable list.

- Shane

On 06/14/2011 12:45 PM, Christopher Howard wrote:
> http://gregorycollins.net/posts/2011/06/11/announcing-hashtables
>
> Just a related note, i was reading the above article about a new hashlib for haskell. They
> discussed how certain hash libs are faster but are less space efficient, and also affected
> by whether ephemeral vs persistent data types are used. Just made me think that maybe data
> structuring might be more important than i had assumed.
>
> Sent from my HTC
>
> ----- Reply message -----
> From: "Shane R. Spencer" <shane@bogomip.com>
> Date: Tue, Jun 14, 2011 8:52 am
> Subject: [aklug] Re: A developer's take on system resource consumption
> To: <aklug@aklug.org>
>
> 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.
>
>
>

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Tue, 14 Jun 2011 12:57:46 -0800