JavaScript profiling/dojo.date.fromIso8601 performance Issues

You might have noticed that retreiving the Abflug/Rückflug-Übersicht on the search results page takes a long time.

Well, not anymore.

I finally had the time to really drill down into this issue with Venkman, the friendly JavaScript profiler. My initial guess was that the massive data transformations and the usage of Dictionaries and Arraylists caused the delay. Boy, was I wrong!

The culprit was: dojo.date.fromIso8601. This function converts an ISO8601 data that is generated from our server into a JS date object. Unfortunately, it takes it sweet little time to do this.

On a result page with a lot of results (well, most result pages have a lot of results) the calls to this function took approx 5 seconds. And the rest of the calls 1,5 seconds.

So I rewrote the code to not use this function so often and voila, problem fixed. Total calling time < 100ms.

(And yes, I probably should have implemented it differently right from the start but this example illustrates the point).

At least in Firefox. IE still takes some time (faster than before but still slower than expected). my initial "guess" is that this is caused by the actual rendering of the result matrix via the DOM.

So I'll profile this as well. Will keep you posted.

Which is also the closing line for this post:

Don't think, profile!

(at least when it comes to performance issues ;-))

Stefan

Download an ASP.NET Tag Cloud Sample

Update:

Rama Krishna Vavilala created a very nice cloud control for ASP.NET. Check out his article on CodeProject.

Great stuff! I recommed using his control instead of ours. It's better! We are now using it as well.

The original post

Todays' post actually violates my "pays my bill" principle so read with caution ;-)

We just released a small feature we call the "Flugwolke": This niftly little page shows you the most popular flight searches on Wingio. This feature certainly is of no use to our average user but we thought it would be cool to do. So we did it ;-)

We really thought hard how to visualize this. Our options were a simple ordered list (boring), a pie chart (nice but does not scale too well above 10 results) and a Tag Cloud. As you see on the page, we decided to use the cloud approach (and hence the name Flugwolke which roughly translates to "FlightCloud" in English).

So I went on the hunt for a working sample in ASP.NET and didn't find any. There are some nice articles (the one on EchoChamberProject being my favorite) but none of them did fit my bill. So I implemented one myself and decided it to share with interested parties.

Download sample ASP.NET tage cloud implementation (in VS.NET 2005/C#)!

The sample shows the following:

• Access the Wingio FlightCloud web service to retrieve a DataTable with the most popular flight destinations. This is live data!
  
• Render the results into a tag cloud

The algorithm used for this sample implementation is pretty simplistic but it's okay for the use case. Check the article mentioned above for more advanced algorithms. The alorithm is very easy to port to ASP.NET.

The sample is "slightly" documented. Use it for whatever you want to use it for.

Cheers

Stefan

Microsoft, waste my time - asp:login & the DestinationPageUrl property!

We have deployed a new version of wingio this weekend. You might have noticed ...

The major new feature is the "Flugspion", which allows you to monitor the price development of flights that you subscribe too. This is a really slick feature because flight prices do vary over time and a nice chart can help you to decide when to book. I saved over 160€ while beta testing this feature ( I am flying to the wonderful land of OZ this summer).

In order to make this feature work, we needed the capability to remember users. And since we use ASP.NET this was a no-brainer because of Personalization & Membership which is built into ASP.NET. It is not fancy (the registration wizard lacks some "state of the art"-features like an "activation mail" or CAPTCHAs but it is okay for our purposes). Nicely done Microsoft!

What's not so nicely done is the freakin' control which wasted one day of my life:

In theory (according to the detailed MSDN docs) you can set the DestinationPageUrl property which determines to what page you are redirected after login. This is especially handy in the case where you have a button (an asp:LoginStatus - control) that allows you to log-in from an homepage. Because in this case I most certainly do not want to be redirected back to the home page but the homepage of our "Flugspion". So DestinationPageUrl to the rescue?

NOT!

To put it simply: IT DOES NOT WORK!

I tried it within a masterpage, outside of an masterpage, etc. No joy. Did some research on the Internet and it seems I am not alone. I guess that I must be doing something seriously wrong because I sincerely doubt that such a bug could have slipped through Microsofts' QA department...

So I had to write some custom code (looks like the following) that handles the "Authenticate" event:

if (Membership.ValidateUser(Login1.UserName, Login1.Password))
{

// Perform the redirect
Response.Redirect(Login1.DestinationPageUrl, true);
}
else
{
Login1.FailureText = "Ihr Anmeldeversuch war nicht erfolgreich - Bitte versuchen Sie es noch einmal!";
}
}

Scary, but that fixed it.

Other than, no problems. I am still a little bit unclear about the localization story of the emails that get send out ( I have the feeling that there is zero native support for this) but this can be easily "done" via dynamically setting the correct filename and manually maintining another set of localized resources for each language (which can't be handled via the normal .resx based process so another step in the build process). Sigh, software from the US and localization ...

Cheers & try it out: The Wingio Flugspion - the easiest way to search for a cheap flight ;-)

Stefan

Dojo - it is a love & hate relationship!

Going back in time for some months. Me, veteran in most things server side decides to start a new venture that will make searching for flights much easier than it is today. Looking at the technologies in my toolbox, I realize that this will not be possible. So I decide to venture into the new strange world of AJAX and JavaScript, which I previously only used for form validation.

Call me naive and an absolute beginner.

So I started doing what one should do in such a case: Make a plan and spend some serious time on research. Buy some books, spend some more time and finally my shortlist is actually short: I decide to use dojo (http://dojotoolkit.org) for my new venture.

My primary reasons for using dojo is the really massive support for AJAX (e.g dojo.Io.queueBind, JSON, etc.) and its great build system.

As a lot of other server side developers I am also quite shocked by the lack of functionality of the default JavaScript class library. Hey, I do need stuff like dictionaries, array lists, etc. And no, I don't want to go back to stone-age and implement this all by myself.

And dojo has all that. Plus cool Gadgets which we currently don't use (as I said, in my earlier post, we are an HTML++ application. Why? Our target group feels more at home with this kind of pages). The source code is mostly documented and nicely written (as I said before, I am a beginner when it comes to JavaScript so take this with a grain of salt - however I can smell bad C# and Java). There's also an active developer community and some great newsgroups.

So, we're all happy campers, right?

No.

Why? The learning curve for dojo is steeper than some other JavaScript libraries out there (e.g. Prototype, Mochikit, ...). And the primary reason for this is the documentation (in other words: the lack of). While there are some docs here and there, it is located in different sources (e.g. wiki, mailing list, tests, site) .. not helpfull when you start.

The good thing however is that once you get over the initial shock, it actually does get better. The tests are a good source for "how-tos" and the code is actually readable. And once you get in "dojo mode", the flow actually starts...

The dojo guys are aware of these issues and working on them. So let's wait.

Executive summary: If you're not too much into hardcore programming and need a simple js effects and AJAX library, don't use dojo. If however you need to do some serious lifting and you need a ".Net framework BCL" for JavaScript, then look no further.

Favorite pet peeve: As with all things coming from the other side of the pond, localization is an issue - there's none. But because of the nice packaging system, you can actually add some code that performs localization (e.g. date names in German) without touching the original dojo sources. As I said, great stuff this packaging system.

Favorite war story: Me being naive, implemented the calls to the JSON web service that retrieves the data from the individual travel agencies via dojo.bind(). This means that dojo is going to use all 2 connections that are available to IE with the result that the browser will not react to any user clicks (e.g. in order to see some detailed info about data that has already been received). Really annoying to the user (Microsoft, please change two connection limit!). Solution was to replace dojo.bind with dojo.queueBind and now everythings works as expected. Thanks guys!

So I say dojo is great, right! Absolutely! But why do you say that you are also using ATLAS then? More on this in one of my next posts..

Cheers

Stefan

Welcome to the Wingio technical blog & news!

My name is Stefan and I am the head IT honcho here at Wingio. For more info on the functional side please visity our News blog @ wingio.blogspot.com.

My background is some fifteen years in IT starting from assembling PCs, via networking (anybody remember yellow cable?) to software development. Which I am doing now for more than ten years in the Internet space starting with ASP1 to nowadays ASP.NET 2.0.

In this blog I plan to share some stuff that I have learned the hard way over the years. It's an attempt to give back what I have received. This is also why this blog is in English and not in German. The stuff that we're doing here is mostly covered in English language blogs so I guess the majority of my readers is not that fluent in German ..

So what will you find in future posts

• Real life stories about some fairly nice pieces of technology
• Pitfalls that we encountered and how to avoid them
• Some rants on the state of the Industry ;-)
• LEGO set reviews (Yes, I do love my LEGO bricks, so much in fact that I actually had to work at LEGO in Denmark for more than a year - if there are some people reading who worked in the Darwin project, please drop me a note!)

What you will not find

• Fan-Boy content
• Religious discussions and comments (religious in the OS/Language/Whatever sense)
• The 24711th announcement of some stuff that XY Vendor just released

One thing that I am going to refer frequently is the "pays my bills" principle. It means that usually we only do things that "pays my bills". So no ravings about the latest silver bullet technology here, sorry.

Since time is money, let's cut it and get dirty...

The technology behind wingio

I assume that you already used our website to hunt for some cheap fares. So what I am saying now is probably no news for you.

We heavily use:

• JavaScript for form validation, DHTML effecs, dynamic content rendering and everything else that can make YOUR experience with Wingio more comfortable
• AJAX to asynchronously load & render the search results that our server generated (So I guess we are more an HTML++ app than a SOA-app but what the hell.. see "pays my bills"). Most of the advanced JavaScript and all of the AJAX stuff is handled by a fantastic product called Dojo (open source, http://dojotoolkit.org). Great stuff! Thanks guys! We also use Microsoft ATLAS in places but more on that later on ...
• A farely complex backend tier that does "all the work" which is implemented in ASP.NET. That layer handles all the nice stuff like localization, skinning (multi-layout), caching, data retrieval,etc. We use classic ASP.NET based pages in combination with Dojo. Dojo communicates with "JSON Services" (like web services but the format is JSON) via a "hand rolled" translation layer (plan to change that eventually).
• A lot of 3rd party components to implement stuff like charting, RSS support, O/R Mapping, etc.

So why do we use open source and products from the "Evil Empire(tm)" at the same time? Well, please see "pays my bills". We simply use what we (YOUR mileage probably does vary) think is best for the job. And obviously my experience in ASP.NET also has some effects on this. I do speak Java but not as fluently as C#/.Net.....

In the next post, I will cover some more ground regarding my experience with Dojo.

Cheers

Stefan