Tales from the Evil Empire

Bertrand Le Roy's blog

News


Bertrand Le Roy

BoudinFatal's Gamercard

Tales from the Evil Empire - Blogged

Blogs I read

My other stuff

Archives

January 2005 - Posts

Separating Object Querying Languages from O/R mapping tools
Sebastien Ros just published a free library that enables you to query an arbitrary object graph using an XPath-like syntax.
It's definitely a great idea to finally separate OQL from O/R mappers. The syntax here seems very intuitive.
It brings us closer to Cw. By the way, wouldn't it be even greater if the Navigator object could be extensible?
This way, you could give it an XML document, for example, or a DataTable, or an object that has a property that is an XML document and be able to seemlessly query across the heterogeneous parts?
But maybe I'm asking too much...
 
http://blogs.dotnetguru.org/sebastienros/index.php?title=querying_over_objects_just_say_eon&more=1&c=1&tb=1&pb=1
 
Update: another, similar approach, but more standards-based: http://www.byte-force.com/sdfxpath/doc/ (source TSS.NET)
Stupid tests!

So OK, so it seems like I'm a supreme nerd:
I am nerdier than 93% of all people. Are you nerdier? Click here to find out!

But the good news is, my wife isn't:
I am nerdier than 14% of all people. Are you nerdier? Click here to find out!

I'm also not very weird:
What is your weird quotient? Click to find out!

Talking about weird...
You are .tar You are rarely seen without your buddy gz. You're talented at bringing ideas together, so they're easier to work with.
and
You are Windows 2000 SP3. You're a steady and reliable friend. People think you're all business, but with your recent therapy you've become a little more playful.
I'm so glad I'm not Windows 1 or Me (see this for the nice descriptions)

But wait, it gets weirder:
You are GODFREY UGO. You are the Chairman of the Contract Debt Investigation and Payment Commission for the government of Nigeria. You have $200 Million that you wish to give away 25%. Your business is 100% risk free.

How to multiply a Unit by a number?
The Unit type exists to represent a length, and contains two different informations: a value and a unit or type. The unit can be absolute (pixels, centimeters, etc.) or relative (percentage, em). They are not lengths in the physical sense because in the relative case, they vary depending on the context. This is just how HTML works with lengths.
So every property that will end up representing a length should be of type Unit.
Now, while Unit is a value type (a struct, if you prefer, as opposed to a class), it lacks the basic arithmetic operators. You can't add two Units, but that's normal, because they may have different units (again, they are not lengths in the physical sense), but you can't multiply them by a number either without writing some code.
An example where you would want to do that is for example the Menu control where we have the possibility to indent the submenus. A menu of depth three will have to be indented by three times the indent property value.
We're doing it more or less this way:
 

Unit Multiply(Unit indent, int depth) {
 
if
(indent.IsEmpty) {
   
return Unit
.Empty;
  }
 
if
(indent.Value == 0) {
   
return
indent;
  }

 
double
indentValue = indent.Value * depth;
 
// I'd love not to hardcode this but Unit.MaxValue is currently private.
 
if
(indentValue < 32767) {
   
return new Unit
(indentValue, indent.Type);
  }
 
else
{
    return
new Unit
(32767, indent.Type);
  }
}

A Gates paradox
I was reading this very informative interview of Bill Gates about rights management and the way it ends made me smile:
Gizmodo: But I think we just disagree.
Gates: No, I actually don't think we disagree.
 
So can we agree to disagree? Or agree not to disagree about our disagreements, at least? Oh well, I'm confused.
Are StringBuilders always faster than concatenation?
While it's certainly a very good thing that more and more developers are aware of the performance problems of string concatenation and of how StringBuilder can solve them, it's not as simple as switching to StringBuilder every time you're concatenating more than five strings.
So just in case you don't know, here's what's wrong with concatenating a lot of strings using the + operator (& for our VB friends)... A string is an immutable object, which means that every time you change it, the old string object gets thrown away and a new one is created, which means allocating new memory. So if you repeatedly concatenate a large number of strings, the memory you're going to spend on that is going to grow roughly with the square of the number of strings.
A StringBuilder, on the other hand, just keeps references to all the string bits, and only really concatenates when you call ToString(). Everything stays nicely linear and you can safely concatenate several millions of strings with reasonable performance (not that it's a good idea, but you can).
Now, it doesn't mean that you should use StringBuilder all the time. For example, a common piece of code that you write in ASP.NET is constructing a client-side script string dynamically from static and dynamic bits (typically, a control's ClientID can be injected in some script that uses the client-side HTML structure rendered by the control). There are three approches you can take to that.
The first one, probably the easiest to write and to read is to use String.Format. Unfortunately, it performs poorly. Use it if readability is more important to you than performance.
The second one is to use StringBuilder, and the third one is to use string concatenation.
The crucial point here is that in the script generation case, we know in advance how many string bits we want to concatenate, which is very different from concatenating an arbitrary number of strings in a loop. Let's look at the last two approaches in details, as simplified in this sample code:


Console
.WriteLine(DateTime
.Now.ToString("HH:mm:ss.fffffff"));
for (int
c = 0; c < 5000000; c++) {
 
int
i = 0;
 
string
a = "a" + i++ + "a" + i++ + "a" + i++ + "a" + i++ + "a" + i++ + "a" + i++ + "a" + i++ + "a";
}

Console.WriteLine(DateTime
.Now.ToString("HH:mm:ss.fffffff"));
for (int
c = 0; c < 5000000; c++) {
 
int
i = 0;
 
StringBuilder sb = new StringBuilder
(15);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
  sb.Append(i++);
  sb.Append("a");
 
string
a = sb.ToString();
}

Console
.WriteLine(DateTime.Now.ToString("HH:mm:ss.fffffff"));

What's interesting is to look at the compiled IL for the concatenation approach.


newarr [mscorlib]System.Object
... lots of array initialization code...
call string [mscorlib]System.String::Concat(object[])

The compiled code does not concatenate each string bit. Instead, it creates an array with all the bits in it (as it knows the size of the array at compile-time) and then calls String.Concat passing it the array as a parameter. This solution is actually faster than the StringBuilder which doesn't make any assumptions on the number of string bits (even though here, we've used the overloaded constructor that specifies the number of bits: this number is just considered a first estimation by the builder).
I've observed this code to perform about four times faster in the concatenation case than in the StringBuilder case. Of course, this test is very primitive and should not be considered to be some kind of absolute truth. For example, I've chosen the number of strings to concatenate quite arbitrarily, and you may find that your own numbers may vary widely from that. As always, never trust someone on performance, do your own tests in your own context.
But as long as you keep your concatenation instructions all in the same instruction (which doesn't prevent you from making it readable using carriage returns and indentations - our VB friends can use the underscore to continue on the next line -), concatenation should be faster in the fixed number of concatenations case.
Callbacks are getting momentum, not only in ASP.NET
The recent launch of the Google Suggest beta attracted a lot of attention to XmlHttp callbacks. Such features where client-side script asks the server for very focused updates to the page without reposting it entirely have been possible ever since frames and javascript exist (I've done a web-based chat application and treeview based on hidden frame posting more than 4 years ago), but the XmlHttp APIs first found in IE 5 and then in MozillaSafari and Opera (without the need to use an ActiveX, which is a great improvement) have made it a lot easier and a lot less hacky. There's even an ongoing W3C attempt at standardizing such APIs (which unfortunately adds a third syntax to the IE and Mozilla syntaxes).
So everyone is now realizing what potential it holds to make better web applications. Here's an interesting blog entry about the Google implementation.
But even this very nice Google feature has been available for ASP.NET developers under an easy to reuse form for years: check out this excellent WebControl.
This being said, to my knowledge, ASP.NET 2.0 remains the only server-side technology to natively support callbacks with ready-to-use server and client-side event-driven APIs.
More Posts