0 reviews
  • Add Review
  • Subscribe
  • Nominate
  • Submit Media
  • RSS

Heaps of trouble

I spent most of today desperately trying to optimize a section of code that I wrote.

Among other things, I'm writing a version of malloc for Gravity Pipe. For those of you who haven't had the terrific fun of writing in C, malloc is a function that lets you set aside a certain number of bits so that you can use them later. The computer knows not to touch them (since you already set them aside) which means that another program won't accidentally write over stuff you were trying to save. How will this be worked into gameplay and combat? Wait and see.

As it turns out, this is actually pretty difficult to write if you want it to work reasonably fast. There are a number of relatively easy ways to get something like this to work, but each one will contain a step--whether it's searching for open areas, writing to those open areas, or deleting the malloc'd space once you're done--which will be very slow.

After a day of working it out, I think I've come up with a decently fast solution which involves a a heap, a second heap which keeps the first heap from growing too large, and hash table.

That's all for today. I need to debug my heap implementation.

Posts

Pages: 1
I still have no idea why you're trying to optimize this before it's even working.
You should be focusing on how good the user interface looks. That's the most important part.
LockeZ
I'd really like to get rid of LockeZ. His play style is way too unpredictable. He's always like this too. If he ran a country, he'd just kill and imprison people at random until crime stopped.
5958
I don't think you two guys understand how programming works
chana
(Socrates would certainly not contadict me!)
1584
Maybe because when it will work, it will be optimized !?
author=LockeZ
I don't think you two guys understand how programming works
Preface: I have no idea how experienced a programmer you are, but as I'm trying to make a career of it, please inform me how optimization is remotely beneficial in this scenario.

From Donald Knuth, "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." This is not a critical program portion. This is not the core of a graphics library, this is not a compiler, this is not something that will be run millions of times across thousands of servers. This is part of a user command in... a text-based game. Even if there's a 10ms change in average execution speed (and that's huge) the chances that the end user will notice are next to zero. If there are (as quack_tape stated) relatively easy ways available to implement this, there's no good excuse not to use them.

Sure, there's theoretically plenty of ways to make stuff faster, but if 90% of the time it's irrelevant, then why bother? Processor cycles are cheap; programmer time is not. If the game ends up slow, run a profiler, find the actual demonstrated bottlenecks, and then optimize. This isn't some sort of design decision that has implications on the entire architecture anyway... it's just a timesink.
You raise a valid point, and it's something I've tried to be cognizant of the whole time I've been writing this. I'm not doing a lot of the more complicated and speedy things that I could be doing (delta graphics, using C instead of python, etc.) because I don't need to do them and they would my code rather bloated.

In this case, when I started I underestimated how fast Python was by a rather significant amount. By the time I figured out I was wrong, I had already finished. No biggie.
Pages: 1