"Throw it a book! They like books."

[flexagon]

We saw Mirrormask last night. I would have probably liked it better if I hadn't already had a lot of exposure to Dave McKean's artwork (showcased nicely here, I admit) and Neil Gaiman's theme of the "other mother" (he did it better in Coraline). And the main characters spend a lot of time being surrounded by circles of strange creatures. None of which is meant to say it wasn't a fine thing to watch on a Monday night.

I have officially started my Christmas shopping, and also bought a CD alarm clock... I have an ongoing hate affair with my current, fairly new alarm clock since its snooze button is much harder to press than its off switch (can you say wrong, wrong, wrong?), and have decided to bite the bullet and get a good clock. What I want is to make a CD that will replicate my friend's Zen alarm clock... it chimes nicely, then chimes 10 minutes later, then 5 minutes later, then 2 minutes later, and so forth. HLM has said he'll help me make the CD. And unlike my friend's Zen alarm clock, it will not have a striker that can occasionally miss the bell. I am excited about all this. Oversleeping every day for the last few weeks* has kind of sucked.

Oh, and by the way, I've largely cracked the code of my evil multithreading bug. It's all about minimizing memory allocation. Whew. From here on it's solvable. That only took 7 work days... :b

*This doesn't necessarily mean I've been late to work, but it does mean my mornings are no fun.

Comments

[jg26.livejournal.com]

I (meaning "we") really need to get an alarm clock. I wake up w/ the sun in general.. which is getting later these days. I don't necessarily want to keep waking up later and later.

Congrats on your debugging success. When you say "It's all about minimizing memory allocation", do you mean heap allocation?

[flexagon]

No alarm clock, for either of you? WOW. I've been told that if one is on a good sleep schedule one shouldn't need an alarm clock... but always held that up as a hopelessly impossible ideal.

I do indeed mean memory allocation on the heap. It's not the amount of memory allocated that's the problem, but rather the number of times that memory is asked for. The heap is essentially synchronized when it comes to allocation/deallocation, and will only let one thread do those things at a time, so if you're doing it really often (and multithreaded) your threads can begin to have to wait on each other.

In case you are curious: we had an STL container (vector) being initialized over and over in a tight loop, and then we were increasing its contents with push_back calls, which sometimes cause more memory to be allocated. Just reserving a bunch of memory right after its declaration was enough to break through a lot of the problem.