Gridgoal: The Startup Log[2] — Its the simple problems that take the longest to fix
For the past day, I’ve been trying to figure out a bug that I caused by making Gridgoal more efficient. Before, I was dedicating a large amount of memory to store a user’s entire daily progress. For a Gridgoal that lasts 7 days, progress would look like this:
{ Day 0:200, Day 1:450, Day 2:55, Day 3:0, Day 4:0, Day 5:0, Day 6:0,}
If the goal lasted 365 days, then I created 365 key:value pairs all initialized to 0. This is a problem. There will be a lot of wasted memory and it just bloated everything. But I use the progress object to calculate everything on the page.
So I made the change and initialized the progress object to {}. Then when someone adds an activity to let’s say “day 4” then it will add “Day 4” to the progress object.
To illustrate the problem, let’s say you have a moving van that is supposed to have 365 empty spots. When you do an activity with the Gridgoal, you’re essentially calling for a specific spot in the moving van and adding the activity amount to that spot. This is what the code does below.
If you remember from above, I stopped allocating the space for the moving van in advance but I was still trying to find a spot in the non-existent moving van. I wasn’t getting an error, but the behavior was not working on only the first behavior. The object would fill with null and then on the second use, everything would be fine. But once the problem was found, it was as simple as adding a check if the progress object was empty. See the code below.
Now Gridgoal works fantastic and is very memory efficient. Take a look at GridGoal.com