ansaurus

Question

Freeing static memory? no, that can't be right

Answer 1

A:

One way I've seen being used in several applications is concatenating the data in the end of the executable, then appending the size of the data itself.

You can then fopen the executable file, go to the end of the stream and read the size of the data, then go back that size and read the resources.

Note that the resources will be exactly as you put them, so organization might be at risk.

I also can't tell if this is a best practice, but it seems to work.

luiscubal 2010-08-31 16:11:16

That's a clever solution. I could tar the resources together and then use a tar library to find all the files inside the archive. If I understand correctly the process will be something like: $SIZE = stat -s%o "executable"; cat resources.tar >> executable; printf "%20i" $SIZE >> executable;

cheshirekow 2010-08-31 16:19:17

Just be prepared for every antivirus under the sun to start complaining when checksums don't match up. ;)

Billy ONeal 2010-08-31 16:29:33

Good point. On a side note, a large program that consumes a huge chunk of system resources, slows down (and second guesses) everything you do, and sporatically prevents normal operation of a system... sounds like a virus to me. My favorite anti-virus software: rdiff-backup.

cheshirekow 2010-08-31 16:42:47

Ok, so maybe not a great solution, but +1 for a clever hack.

cheshirekow 2010-09-01 05:53:17

Answer 2

+4 A:

As Tomaka17 says, you don't really have to worry about it - if you never touch that resource, it will never be faulted in, and it won't consume physical memory. When you load a DLL/so/whatever, it really only maps the file into memory; trying to access that file is what results in actually reading the file, piece by piece.

Paul Betts 2010-08-31 16:24:41

so I will definately use the resource *once*, at the beginning of the program. i.e. load a png file, turn it into a native bitmap to display on the GUI. After that, the png isn't needed anymore.

cheshirekow 2010-08-31 16:26:21

This is not strictly true -- because in all likelihood that data is going to be on the same memory page as some other items that you *are* using.

Billy ONeal 2010-08-31 16:29:03

@Billy Granted, but images are pretty big, and pages are only 4k. It's far better than the naive view of the entire DLL being loaded verbatim

Paul Betts 2010-08-31 16:33:54

@Paul: Touché :)

Billy ONeal 2010-08-31 16:34:30

@cheshirekow The PNG data will eventually be reclaimed by the OS if your code never touches it. The read-only pages can be discarded because they are never written to, and will be paged in on demand again if needed. The only cost to your program is some virtual address space.

karunski 2010-08-31 18:38:17

So, really the only reason you'd worry about this is if you were trying to reduce startup time (a legitimate concern). If your app starts up fast enough, I wouldn't worry.

Paul Betts 2010-08-31 20:57:51

@karunski, @paul betts, Thanks. That completely answers my question. So it's not something to worry about unless I run into issues of it loading slowly.

cheshirekow 2010-09-01 05:52:37

ansaurus

tags:

views:

answers:

Freeing static memory? no, that can't be right

related questions