Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

MorphingDragon

macrumors 603
Original poster
Mar 27, 2009
5,159
6
The World Inbetween
The University has random contests once in a while for... well whatever they feel like giving away. The limitation is that it has to be a high-level OOP programming language and it can't use premade libraries to achieve the given task.

Anyway, this time is to make a terminal program which will decompress a 5GB Zip File. Whoever's Application uses the least memory for the amount of time it takes to open the zip file wins.

I have some memory management questions.

Does an Autorelease pool adhere to data encapsulation?

How costly is an auto release pool compared to just using retain/release manually.

How do you free up memory from C primitives? (I know like... no C) Both on the stack and using pointers.

Can C/Objective-C stream raw data to a file on the disk instead of memory? How would I do that?
 
Code:
int i = 0                           // C manages the memory for you. The memory's released when the variable is out of scope
int *j = malloc(sizeof(int))        // You have to release the memory with free()

By the way, I think it's somewhat strange that you have to use a high-level OO language. If you want to keep memory usage down, C is the language to go with. Also, ZIP files can be compressed using various techniques, so since you aren't allowed to use existing libraries, you'll have to write a whole bunch of code from scratch.
 
Code:
int i = 0                           // C manages the memory for you. The memory's released when the variable is out of scope
int *j = malloc(sizeof(int))        // You have to release the memory with free()

Thanks

Code:
By the way, I think it's somewhat strange that you [I]have[/I] to use a high-level OO language. [B]If you want to keep memory usage down, C is [I]the [/I]language to go with[/B]. [/QUOTE]

I think thats the point. Give them a language that naturally has more bloat than C and make it as efficient as possible.

[quote="(marc), post: 11196134"]
Also, ZIP files can be compressed using various techniques, so since you aren't allowed to use existing libraries, [B]you'll have to write a whole bunch of code from scratch.[/B][/QUOTE]

I think thats also the point.
 
Also, ZIP files can be compressed using various techniques, so since you aren't allowed to use existing libraries, you'll have to write a whole bunch of code from scratch.

But why from scratch? There is plenty of open source that you could copy from and just make some small adjustments to make it take advantage of the OOP environment. It is not for production, so licensing will not be a concern.

But I am not getting "least amount of memory for the amount of time". If your code uses twice the memory of another one that takes three times as long, yours would come out ahead, right?
 
But why from scratch?

Its a competition. Competitions have arbitrary rules.

Thats reason enough I suppose. Though it might be to weed out the incompetent programmers?

But I am not getting "least amount of memory for the amount of time". If your code uses twice the memory of another one that takes three times as long, yours would come out ahead, right?

Yes, this particular problem is about efficiency, not pure speed. (I'm not sure how they would get the score though)

We get the rest of the information later. This is just what I know from the posters they've left around the CS department.
 
Thanks



I think thats the point. Give them a language that naturally has more bloat than C and make it as efficient as possible.



I think thats also the point.

Will the solutions be put online? I'd love to take a look at the code when it's finished!

EDIT: I got a bit intrigued on the subject, so I did a bit of "research" about how the JVM works. I found this. At the very end, it says "you can see that the garbage collector only starts to work when the free memory is getting close the specified maximum, 64MB". I don't know if that's really true and I also don't know how the Objective-C runtime handles autorelease pools / garbage collection. It's just a thing to keep in mind, especially for the CS department during evaluation. Do you know how they deal with these problems?
 
I personally believe it would be possible to write an objective-C program without relying on Autorelease, though you could setup a pool just to catch anything Apple shoves into the autorelease pool without you knowing.

You would have to change the normal objective C paradigm that methods that return an object autorelease it before it returns though. But if you use alloc/init instead of convenience methods you should be fine.
 
As an Amazon Associate, MacRumors earns a commission from qualifying purchases made through links in this post.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.