programming – I Grok2!

C — How to check how much time a section of code takes to execute.

This requires use of standard C library support for the clock_gettime() function. This function returns clock time as a data-structure (struct timespec) that includes the the clock time in seconds and nano-seconds.

Call this function one time before the section of code to evaluate and once after and then take a difference of the end time versus the start time to figure out the time taken in the section of code.

#include <time.h> // for the clock_* APIs and struct timespec

struct timespec timespec_diff(struct timespec end, struct timespec start)

{
    timespec temp;


    if ((end.tv_nsec-start.tv_nsec) < 0)
    { // If this is the case, then the seconds values are different by atleast 1.
        temp.tv_sec = end.tv_sec - start.tv_sec - 1; // Borrow one second from the seconds field...
        temp.tv_nsec = 1000000000 + end.tv_nsec - start.tv_nsec; //...and use it in the nano-second field.
    }
    else
    {
        temp.tv_sec = end.tv_sec-start.tv_sec;
        temp.tv_nsec = end.tv_nsec-start.tv_nsec;
    }

    return temp;
}

void testThis()
{
    int i;
    struct timespec start, end, diff;


    clock_gettime(CLOCK_REALTIME, &start);

    for (i = 0; i < 100000; i++)
    {
        x = i * 45;
    }

    clock_gettime(CLOCK_REALTIME, &end);

    diff = timespec_diff(end, start);
    printf("Section of code took %u seconds %d nano-seconds\n", diff.tv_sec, diff.tv_nsec);
}

C Maintenance Notes

Note to self: If modifying a structure to include a new field, search for all uses of the data structure and check that this new field is initialized everywhere and not just in the place you wanted to use the new field!

Fragmentation when allocating memory

To reduce fragmentation specially in high-activity code, allocate temporary buffers (buffers that will live only for a short while) from a separate memory pool. The idea is to avoid long-lived buffers and short-lived buffers from being allocated from the same pool.

Coding and Holding The Big Picture in Your Head

I find that I am often unable to complete some piece of code unless I have a mental picture of the whole thing in my head. And this is a huge problem. For small things, it is fairly easy to get a mental picture of what needs to be done and my coding happens fast. But for something that is larger, requiring perhaps a multi-step process with things that can go wrong in each or all of the steps, it is much harder. I keep procrastinating for days on end until my puny brain has wrapped itself around whatever needs be done end-to-end and I feel that I will be able to take care of all the loose ends and all corner cases are considered — mentally. Only then can I start coding.

But this method does not scale and also it’s hard to give a project schedule and tell when you’ll be done with some module :-(.

I need to figure out some way of divide-and-conquer programming where I don’t need to have the entire thing in my head, but have just pieces of it in my head at a time, code that piece and be comfortable that the particular piece has been coded correctly — and that the way it’s been coded it will interact correctly with all the other pieces making the old adage of the sum of the parts being larger than the whole come true.

Oh well. I guess I cannot be everything all the time. Back to wrapping my head around this current problem…why is it that people find web-development easy and I keeping finding it hard and wondering why no-one sees that it is complicated distributed programming? That things can go wrong anytime and everywhere.

How do you deal with coding of such nature? Let me know in the comments.

If you are going to print tablular information…

…in a console as a result of some debugging or control command, then try to ensure that any column that uses string or such similar output does not have spaces within that column. This helps with parsing output using tools like awk that are able to split by column and help with subsequent slicing and dicing of the information (specially when debugging).

Using the right programming font

After playing around a bit with various fonts and color schemes due to increasing eye-strain, today, I finally settled on using “Lucida Console” with “ClearType” font smoothing for C/C++ programming (under Windows with Emacs and Vim) and realized something — when the code looks beautiful (as it does with this font combination), I feel like writing beautiful code :-).

I now use Lucida Console Regular, font size 11 with ClearType font smoothing under Windows.

(UPDATE: Mensch is now my new favorite. On my Emacs on Windows XP, Mensch looks mostly like Lucida Console, but has minor enhancements (like 0 with a dot in it to distinguish it from O) that I like)

Programming is all about decision making

As a programmer, you are continually making decisions when you program. Both at the macro level and the micro level. For any project, you have to select the programming language, the tools and the environment. Then as you design, you have to choose continually among multiple ways of doing anything. As you code, you continually are choosing among many ways to write the code. You are continually reformatting and rearranging code and even refactoring because you are not able to decide if one way
is better than another. The problem is that, usually, the decision making required is trivial. But the sheer number of times you have to decide stuff is what slows down any programming task.

I think people who complete / finish projects are people who do not sweat over all details when programming. For most decisions, when the need to make a decision arises, they quickly choose one of the two or more choices without thinking about it and do not second guess their choice. So they continuously make progress and take one path to the end — they do not spend their time vacillating over what to do at each decision point. If some decision was really bad, it will become apparent enough — then you only need to decide (:-)) if you need to rewrite the part of the code starting from where a wrong decision was made.

“Premature Flexibilization”

The author of this coins a new phrase — Premature Flexibilization:

…the practice of adding complexity to your code to make it more “flexible”, in anticipation of future change.

The article, triggered an “yes” response in me 🙂 because I felt the same way many times.

In all my coding, I find that I waste a lot of time doing exactly what the author of that article calls “premature flexibilization” — trying to make code as generic as possible, trying to cover many cases that are currently not present, trying to cover all kinds of input. Though it is a good habit, I find that it contributes negatively to project completion and most times, all the genericity, etc was really not used. I have found that it is better to follow the agile practice of YAGNI and code to the current exact requirement and later go back to refactor code when another requirement for the same code comes it to make the code flexible and generic to cover the original and new cases. That way the code goes organically, does exactly what is required and the project gets completed.

One thing though is that it requires some discipline when revisiting the code the second time around to make sure that you test the original requirement is still being met.

I think one of the reasons for the effort spent in making the original code flexible is so that I don’t have to revisit code (mentally for me code maintenance is possibly one of the hardest thing to do).