However a colleague of mine suggested that it may be due to the cost of pass-by-value as opposed to pass-by reference.

So I wanted to sort it out and this simple test is the result. After all, the first rule of profiling is “measure, measure, measure” (OK, the first three rules). The following code compares string comparisons as pass-by-value, pass-by-reference and inline, as well as an integer (constant) comparison.

The profiling code:

        function compare_value($str)
        {
            if ($str == 'MekTek')
                ;
        }

        function compare_ref(&$str)
        {
            if ($str == 'MekTek')
                ;
        }

        $string = "MekTek";
        $integer = 0;

        $now = microtime(true);
        for ($i = 0; $i < 10000000; $i++)
            compare_value($string);
        echo("value: " . (microtime(true) - $now) . "\n");

        $now = microtime(true);
        for ($i = 0; $i < 10000000; $i++)
            compare_ref($string);
        echo("ref: " . (microtime(true) - $now) . "\n");

        $now = microtime(true);
        for ($i = 0; $i < 10000000; $i++)
            if ($str == 'MekTek')
                ;
        echo("str: " . (microtime(true) - $now) . "\n");

        $now = microtime(true);
        for ($i = 0; $i < 10000000; $i++)
            if ($integer == 0)
                ;
        echo("int: " . (microtime(true) - $now) . "\n");

The result:

    value: 5.2698040008545
      ref: 5.4901170730591
      str: 5.3154430389404
      int: 1.0382018089294

Isn’t that fascinating. I love it when profiling returns obvious results. The time taken to compare a string depends on the length of the string, regardless of other factors.

The message is clear. Do not compare strings in performance-critical code. Use constants instead.

Even more subtle:

if (i != 0)
    foo(i);

In this case the code is 100% correct; it conforms to most coding conventions and there’s nothing wrong with it, but the fact that the single-statement body of the ifstatement is not enclosed in braces may be bugging you, because you might be thinking in the back of your head, gosh, somebody might insert another line of code there

if (i != 0)
    bar(i);
    foo(i);

… and forget to add the braces, and thus accidentally make foo(i)unconditional! So when you see blocks of code that aren’t in braces, you might sense just a tiny, wee, soupçon of uncleanliness which makes you uneasy.

Now I have heard this argument before:  that even single statements after if (and while and for) statements should be in braces to prevent some klutz coming along and really breaking something.  Now I don’t buy this at all.  Why?

1. Any programmer who would add the above statement without realising the implications should not be touching any of your code for any reason.  If they are truly that terrible then the above problem is the least of your worries.  What is going to happen when that programmer tries to code something non-trivial?  Backup your codebase and keep the media handy.  You are going to need it.  (Oh sorry, I meant branch your codebase using the SCM tool you use, right?)
2. I  think these “mandatory” braces makes the code look awful: crowded, verbose, and … well .. wrong.  Just why is that single statement in braces?  Oh that’s right – they all are.  It is bad enough that the ambiguity of if-if-else requires extra braces.  I like my code minimalist – I like to see everything.  A lot of refactoring is all about making the behavious of an if statement a single line [1]; don’t waste that effort.
3. Martin Fowler formats “guard clauses” with the entire if statement on one line (“guard clauses” have no else leg).  I like this format, and he describes why this makes the programmer’s intention clearer.  Braces?  Blech! [2]
4. This technique is really a piece of flim-flammery to create a syntactic tarpit.  I believe there are more important drivers for how code if formatted and organised.  Screen space is valuable.

I get that this is going to be “horses for courses”.  I suppose you like this idea or you don’t.  I hate it.

I think doing things that aren’t right to compensate for (to put it bluntly) incompetence is not the right way to go.  You can never compensate for incompetence.  It just finds new means of expression.

I am going to put this up there with the One True Brace Style argument, about which I have equally strong and pointless opinions.

[1] Refactoring, Martin Fowler.

[2] Refactoring, Marting Fowler.  pp 250-254.

It is easy to say yes, but I have an objection.  The caveat is that software is not free.  The problem is not even that software is expensive.  The problem is that good software is rare.  Good tools, good frameworks, good environments.  Rare.

My personal experience with V-Sec (now defunct) says that writing, maintaining and changing any system is a non-trivial task.  I suspect a lot of the talk about “agility” is by people with multi-million dollar VC budgets funding the best-of-the-best hungry for stock options.  Things will really change when the “software” part of the equation reaches zero friction.  Then … watch out!

VentureBlog: Chris Anderson Strikes Again: The Economy of Abundance

Eric was (unsurprisingly) talking about changing the standard (and therefore browser behaviour), which I had (also unsurprisingly) considered to be way beyond the scope of what I could consider.  My approach was therefore to focus on the build system, which was not only the part of the equation I knew best, but also avoided any standards/browser issues.

But what if I removed that limitation?  If I wanted to add a processing capability to CSS, what would I change and why?  Broadly I see three alternatives.

Build stage

Processing is performed at the build stage and the resulting CSS is loaded onto the webserver as a static page.  This is the approach I took previously.  There is no change to the standard and no change to browser or webserver behaviour.

If this was specified as a standard, it would not so much be a standard defining a message format (which is what CSS really is), but a new language.  This would be in addition to the existing standard.

It may also change the nature of developing CSS; it may no longer be useable by creative people, who may need a build systems, and then we go down the path of programmers, infrastructure, and so on.  A worse idea. (While the idea that there are folks out there creating systems without the guiding light of build systems and, even worse, SCM makes my heart flutter, I can accept that this is a boon to creative people and a necessary evil if they are to stay creative).

This approach would be fine for a specific project or shop that “rolled their own”, or as a product that pre-processed CSS.  Such an approach would be transparent to both the webserver and the browser.

Server-side

Variables are resolved at the webserver and the resulting CSS is passed to the browser.  The CSS standard is unchanged and browsers do not change, but there is a new standard for the “raw” CSS and webservers must change to process “raw” CSS and produce “standard” CSS.

For a start this introduces a new standard for the “raw” CSS, adding to the exisiting standard for CSS.
While webservers have long handed of all sorts of processing (e.g. ColdFusion, PHP, etc), the idea of mandating some form of inbuilt processing just seems wrong to me.  It changes the model too much.

Again this approach would be fine for a specific project or shop that “rolled their own”, or as a webserver plugin product.  Such an approach could only run from specific servers, but would be transparent to the browser.

Client-side

The webserver passes the new style CSS files to the browser where processing is performed.  The CSS standard and browser behaviour both change.

While the idea of changing browsers the web over to a new way of doing CSS makes my head spin, this is easily the best solution.  It maintains the focus, direction, architecture and relationships of CSS.  So while *how* CSS works has changed, the *way* CSS works hasn’t.  It is also the only solution that keeps *one* CSS standard.

This is clearly the preferred standards-based solution. 

Summary

In some ways I have come the long way round and ended up where I began.  The naive solution to this problem would be the same as mine, I suspect – change the existing standard and add the features you want.  But it is always wise to consider the alternatives.

I had been thinking about this for a while, and was considering coming up with some sort of CSS generation language.  Then, as these things happen, I read CSS Repeats Itself and everything became clear.

The problem

The problems with CSS I would classify as:

• No variables.  There is no way to set and re-use variables in CSS.  This means that to make a width or height or margin (or anything) consistent, you just have to set the same value everywhere.  To make it worse, if you want to change the value, you have to change it everywhere.  If values collide, your global replace is going to break something.  If values are in different stylesheets … well … good luck!
• No expressions.  There is no way to say “this equals twice this plus that” in CSS.  You have to figure it out by hand and hard code the value. If one of your values change, you better remember what to re-calculate (after changing all the instances by hand, that is).
• No includes. There is no way to include a CSS file within another CSS file.  This must be done by importing multiple stylesheets in the final (X)HTML document. This hides dependencies between CSS files and prevents reuse.
• No inheritance.  There is a sort of broken implicit inheritance in CSS, but it is totally opaque (to me, anyway).  I would rather express inheritance explicitly, rather than by the imposition of obscure ordering and specificity rules.

You can sort of see why this happened.  Without variables, expressions make less sense, as do include files.  I think (true) inheritance was considered out-of-scope :p

Towards a solution

In CSS Repeats Itself the challenge was to solve this with XSLT.  Well, I don’t know XSLT, so that is not an option.  Also the implication was that this would be an on-the-fly thing, though I am not sure if that was specific to a specific server or a suggestion for a “grand new Internet architecture”.

I was more interested in a solution for a developer like myself, so my solution was always going to be in the world of build systems (where I believe all such things belong).  Looking at the example it struck me that most of what we want to do we already have the tools for (surprise, surprise).  So I took about ten minutes of my time, and reworked a project using:

• cpp
• make

Not quite the sexiest set of tools now-a-days.  But they get the job done, and they work in my environment!  (Always a plus).  I would hate to think of a development environment that didn’t have this sort of capability, but I am sure they exist *sigh*.

My solution

This is a quick example I cooked up, based on the example in CSS Repeats Itself.  It is more to show what could be done, than what you should do.

Makefile

 file.css : file.pcss
         cpp -x c -P -C $? -o $@

I have created the “pcss” file extension, meaning “pre-processable CSS”.  So file.pcss is our source file, from which we build our CSS file, file.css, as part of our system build.  For a well setup project, this should not introduce any wrinkles.  The only issue I can see, which is hopefully minor, is that projects without *any* build phase (e.g. PHP projects) may not have a nice place to slot this in.

The command breaks down as follows:

• cpp is the C pre-processor.  It is designed to work on “C”, but we can bend it to our will.
• -x c treats all files as “C” files, which is just as well because it has no idea what a .pcss file is.
• -P turns off ‘#line’ commands which would ruin our file.
• -C keeps any comments that might be in our code, though we might want to turn this off.

file.pcss

#define LC 200px
#define RC 150px
#define WIDTH 550px

#include “3col.pcss”

3col.pcss

body {
    min-width: WIDTH;
}
#container {
    padding-left: LC;
    padding-right: RC;
}
#container .column {
    position: relative;
    float: left;
}
#center {
    width: 100%;
}
#left {
    width: LC;
    right: LC;
    margin-left: -100%;
}
#right {
    width: RC;
    margin-right: -RC;
}
#footer {
    clear: both;
}

The make command creates file.css:

body {
    min-width: 550px ;
}
#container {
    padding-left: 200px ;
    padding-right: 150px ;
}
#container .column {
    position: relative;
    float: left;
}
#center {
    width: 100%;
}
#left {
    width: 200px ;
    right: 200px ;
    margin-left: -100%;
}
#right {
    width: 150px ;
    margin-right: – 150px ;
}
#footer {
    clear: both;
}

I have made the three column layout an include file, as it may be re-used for many projects.  The parameterisation of the layout means not only does it remain consistent when it is changed, but every project can use different values while using the “same code”.  An obvious advantage to any programmer, but a bit lost in the CSS world.

Summary

The solution above is simple and should be easily achieved in most development environments (so I assert without proof).  This solution:

• Solves the variables problem by using macros to define constants.
• Solves the include file problem through the preprocessors “include” function.
• Partially solves the expression problem.  We still cannot use expressions, but we can use macros to put the each hard coded value in one sensible location (i.e. with their related variables).
• Does not solve the inheritance problem.  We can make some things better, but the solution may be as complex as the problem, and we still have to contend with CSS’s internal model.

Caveats

When I generated this example, I noticed (belatedly) that these is a problem with it.  In file.css one of the expansions evaluates to “- 150px ;“.  This is because the C preprocessor inserts space around macro expansions (for reasons which are too mind bending to go into here).  This is a problem because I am not sure (i.e. I don’t know) if this is going to be alright or not.  “C” is pretty robust about such things; I doubt whether CSS is so robust.  This means that even using this solution, you have to be careful to avoid such constructs.  You will need to do something (admittedly sub-optimal) like:

#define RC 150px
#define NEGRC -150px

I have not tested this extensively, and suspect there may be other cases that make CPP barf!  Also in my research after writing the bulk of this article (see below) I found much concern about id tags (e.g. #blah) being mistaken for cpp directives.  This is possible, if the id formed a reconizable directive.  AFAIK unrecognised directives are passed through unchanged, which is what we want.

Postscript

While following up the inserted whitespace problem, I came across Using a C preprocessor as an HTML authoring tool, which is the same thing for HTML (all the way down to the same CPP arguments).

Then I thought; well, this is all pretty obvious, someone else might have done something similar … and they have.

Precompiling CSS with Extensions – A Crazy Idea?

CSS Preprocessor

CSS Preprocessor – Take 2

The Constants Gardener

CSS-SSV

This is the competition:

The contest is about compressing the human world knowledge as well as possible.

If your compressor compresses the 100MB file enwik8 x% better than the current record, you’ll receive x% of the prize.

This strikes me as a good thing.  But where they lose me is when they start to talk about AI. 

If you can compress the first 100MB of Wikipedia better than your predecessors, you(r compressor) likely has to be smart(er).

… being able to compress well is closely related to acting intelligently …

Say again?  Let’s think about this, for a moment (that’s all it takes):

• I do not get how compression relates to intelligence.  They go on about matching patterns, and prediction, but I do think the “pattern detection” in LZW (for example) is really pattern detection in the AI sense at all.  Nothing is done with these patterns but transcription and mappings. 
• They have also confused where the intelligence is.  A compression algorithm is the result of intelligence, it is not an (artificial) intelligence operating in its own domain.  The intelligence they are measuring (if any) is that of the creator, not of the compressor.
• Their metrics are plain wrong.  The prize is awarded for the compression of a known piece of text.  This seems to me to be a flawed approach.  Even if people were to attack the problem with integrity, the winning solution would almost certainly be “fitted” to the data.

Human Knowledge Compression Contest: Frequently Asked Questions & Answers

1. Ignorance

2. Stress

3. Boredom

4. Human frailties

Categories of error

“We can either categorize based on root cause in the code (e.g., null pointer dereference, failure to unlock after acquiring a lock, buffer overrun, etc.) or based on a higher level reason for the mistake (e.g., improper error handling, typo, copy and paste, etc.) … we choose the latter …”

1. Ignorance

2. Copy and paste

3. Error handling

4. Off by ones

5. Typos

The article then goes on to make a case for static code analysis tools.

Embedded.com – Avoiding the most common software development goofs