debuggable

With JSConf.eu coming closer, I slowly have to start preparing my talk, which mostly means hacking on node-dirty.

I have a few goals for the project. My main interest is challenging a few assumptions people have about the performance and complexity of database systems. Most of that is material for another post and my talk itself, but today I'd like to talk about hidden classes in v8.

One of the things that is really fast in v8 is property lookups. This is due to an optimization that creates hidden classes for an object.

I could go into a lengthy explanation of how that works, but instead I'll invite you to see for yourself.

Consider the following two examples and guess which runs faster, and by how much:

Example 1:

Example 2:

If you have guessed example 2, congratulations! Bonus points if you have also guessed that example 2 is a nifty 10x faster than example 1.

For those familiar with v8, you probably already know what is going. For those who don't, let me explain.

In example 1, every time you are setting a property on the o object, v8 is creating a new hidden class that defines the "data structure" of the o object to optimize property lookup performance.

In example 2, we are initializing these "hidden classes" the first time we create our o object. So when we are overwriting these properties later on, it is blazing fast, because v8 already knows how to efficiently lookup those properties.

So if you're writing node.js code, the lesson learned here is that it is much faster to work with existing properties in v8, than to add new ones.

In my next version of dirty I am planning to take advantage of this behavior by pre-allocating properties before they are actually used. This will probably require a little trickery to map user-defined keys to pre-allocated properties, but it should result in an overall 10x performance boost for setting new keys.

Let me know what you think / if you have other clever v8 hacks to speed stuff up : ).

--fg

PS: You can read more about hidden classes in the v8 docs.

Sorry for the lack of post, some stuff came up this week, and the hour / day to write this series was needed to deal with it. Anyway, it's overall good news, so I hope to continue this series either next week or the week after.

--fg

Monday's are a bitch. You are confronted with all the stuff you didn't finish the week before, and forgot about over the weekend. Everybody is a little cranky, and I found myself much more likely to give into procrastination or occupying myself with busy work.

I'm not sure what the solution to a great Monday is, but I think a combination of my upcoming weekend habit changes together with planning my tasks on Sunday night would be helpful.

This post is more of an update on my last days, I'm playing beach volleyball every Monday night, so I had no time writing a longer post for today.

Saturday's Productivity

1. Productive work: 0,98 h
2. Busy work: 2,33 h
3. Procrastination: - (not tracked, weekend)

84 lines of code added, 28 deleted in 1 project

• I got a lot of small stuff done, like working through various paper work and cleaning my home office
• Coding productivity was almost non-existant as I hit roadblocks with some API design

Sundays's Productivity

1. Productive work: 1,85 h
2. Busy work: 0,60 h
3. Procrastination: - (not tracked, weekend)

406 lines of code added, 341 deleted in 1 project

• I had a really great session refactoring some code for my node-mysql module

Mondays's Productivity

1. Productive work: 2,03 h
2. Busy work: 5,30 h
3. Procrastination: 0,95 h

Time after 6pm: 0,5 h

288 lines of code added, 48 deleted in 2 project

• I had a hard time focusing which directly resulted in more procrastination and especially busy work.

--fg

Weekends are a weird thing when you love what you are doing. Most weekends I have one voice in my head that pushes me to work, and another one that tells me to relax and have some fun.

It's tough, because I always have a lot of ideas for interesting projects, and weekends are about the only time when I can just hack on something for the fun of it. And of course, we are also bootstrapping a startup, so that is very hard to do without putting in some hours over the weekend.

I generally don't have an upfront plan for my weekends, so I mostly just do what feels right at any given moment, be it some hours of coding, some beach volleyball, or playing forkmaster with a few friends. There is usually also one night of hanging out with friends drinking.

This is nothing I'm proud of. It's 2 out of 7 days a week that go by without a strong vision. These weekends feel more like a "break" than a vacation. There is little adventure or heroic work ethics that I can look back at when starting out on Monday.

So for next weekend, I will try to work out a clear plan that will make it a wonderful experience including some well-defined time for serious work. By having an upfront plan, I expect myself to be more emerged in both the fun, and the work with less confusion in my head about what I should be doing at any given moment. Ideally I'll leave the weekend more refreshed than usual, while still having made a nice dent into my backlog.

After that I might also try a weekend with no computer / iphone access. If that yields considerably better results, I just need to get my weekly productivity levels high enough to make this possible.

Yesterday's Productivity

1. Productive work: 2,80 h
2. Busy work: 4,40 h
3. Procrastination: 0,37 h

Time after 6pm: 0 h

271 lines of code added, 172 deleted in 2 projects

• Busy work is still high due to the fact that the box that his site is running on is acting up, and I'm working on migrating everything to vps.net.
• There was a beach volleyball tournament right after work, so no after-hour working
• Procrastination levels are still excellent. I played one short game of SC2 and one game of foosball, that's reasonable for my taste.

--fg

PS: How are you spending your weekends? What would you like to change?

This is post #2 of my programmer productivity series.

Before I embark on trying out various productivity strategies, I need to establish a set of metrics that will help me understand what works, and what doesn't.

For now I decided to keep track of two things:

1. My time, using a daily journal where I enter every task I am working on, and the time spent on it.
2. My commits, as well as the lines of code I add / delete throughout my day

If you want to follow along, I am using a simple notebook for my time tracking. I write one task per row, using the following format:

• 09:23 - 09:26 Coffee & Planning today's tasks (3m)
• 09:26 - 10:30 Work on setting up new server (1h 3m)

By writing out the time I start and end my tasks, it's pretty hard to miss an item.

As far as commits are concerned, I whipped up a simple node.js script that you can download here. To use the script, copy it anywhere on your machine (maybe you like /usr/local/bin/gitloc ?), and then add it to your git post-commit template hook like so:

$ cat /usr/local/git/share/git-core/templates/hooks/post-commit
#!/bin/sh
/usr/local/bin/gitloc

This will automatically track the commits in all new repositories you create. If you want to track an existing repository as well, simply do "git init" in the projects root directory, and the template hook will be copied in.

The CSV file created by the script looks like this:

2010-08-12 17:00:09,8eb212e,Implemented initial map display,142,130,/Library/WebServer/Documents/tvype/portal
2010-08-12 18:34:22,1fa8859,Initial billing code,86,2,/Library/WebServer/Documents/transloader.transload.it

The columns after the commit subject are the lines added / removed. The last column is the path of the project the commit was made to.

Analysis

As far as evaluating my time spent, I have come up with a simple system of classifying my task log entries into three categories:

1. Productive work: I'm creating value for other people (clients, transloadit customers, etc.). If I did this all day, I'll reach all of my goals.
2. Busy work: Answering emails, meetings, staring at the screen with little results, fixing bugs, even writing this blog post series (It's not productive work unless I'll make a living selling productivity advice, which I won't). If I did this all day, I'll end up getting very average results.
3. Procrastination: Reading news, lunch (if longer than 30 min), checking emails in an unproductive way, playing games. If I did this all day I'd be homeless in no time : ).

Of course the lines are always a bit blurry. My advice is to assign a task the category you intuitively think of first. If you must, split the task up in 50% of each category. Skip to the bottom of this article to see my summary for yesterday.

Regarding the commit log, for now I'll simply count:

1. Lines added
2. Lines removed
3. Projects worked on

Ideally I will strike a balance here. Never < 100 lines / day, but >= 1000 is way too much as well. This might be a "programmer productivity" series, but many of us have other tasks that would definitely get neglected if we only wrote code all day.

Yesterday's Productivity

And here comes the promised analysis from yesterdays logs:

1. Productive work: 4,03 h
2. Busy work: 4,60 h
3. Procrastination: 0,45 h

Time after 6pm: 1.5.h

274 lines of code added, 186 deleted in 3 projects

A few thoughts on those numbers:

• There was a 2.5 hour meeting with our client yesterday. That's the first time we had a meeting that long and hopefully the last time ; )
• I won't add "Procrastination" that happens after 6pm to the numbers. If I choose to work after 6pm, fine, but if I like to play instead that's cool. There is no reward for burning out.
• The 0,45 h procrastination are from a SC2 game I played with Tim after lunch. Damn you Blizzard ... . There was also 5 minutes of unproductive email checking / following a link to Facebook.

Coming next

My next post will look into productivity killing patterns and habits and how to fight them.

I won't start setting specific goals until I have collected a little more data about my current productivity.

--fg

PS: My friend Mark Grabanski wrote a post on various productivity factors. Good thoughts, especially on the importance of "tools".