"Performant code" - The writing on the wall

Whether it's the battery life on handheld devices or the browser speed on PC, the writing on the wall is clear for MS.... write "performant" apps/systems or be left in the dust.  I feel, at MS,  too much emphasis is being given towards coming up with different programming models/APIs rather than making the most basic things actually work. 

 I cannot help but get frustated when I notice the performance difference between bing maps vs google maps, IE vs Chrome, WP7 vs iPhone (even with Aqua/glass UI effects enabled)... I could go on and on... 

 I can understand the move to managed programming environment but then, Android side also uses Java...

Amen brother.

I only started using Google Chrome last week (for web-dev testing purposes) and I was skeptical about the whole "it's fast" thing, but no. There's no hype or hyperbole, it really is fast. Everything from startup, the UI, page loading/rendering, and client scripting. I especially love the ultra-responsive UI which makes a refreshing change from the click-and-wait experience with IE (and seemingly, Windows in general).

@W3bbo: Google's plan of attack on "personal" computer is clear...  make compelling apps available over the web, counter the advantage of local computing by making "web os"... basically a super fast container for web apps. Of course, the achillees heel in this approach is the speed of the internet. 

Last year Google tried to play chicken with internet service providers by threatening to do 1GBPS lines direct to home internet service all by it's own.  Of course, it is ridiculously funny because, if they ever embark on that approach they will quickly empty their vast cash reserves before they could even pay fees to 10 municipalities in the country ....ROFLMAO....

I still hope to see Bartok and Phoenix reach productization and increase the performance of high-level type-safe intermediate code for all. The efforts to narrow the performance gap should be kept in high-gear to secure existing investments and the loyalty of a generation of programmers.

Google's Go looks very promising although the syntax will take some getting used to. It's not a purist language in many respects but it has some pretty appealing design points ("go-routines" and duck-typing are high on the list in my oppinion; dynamic is great but not a substitute for duck-typing). It will be interesting to see the performance of applications built in Go, as the Go software stack rapidly matures. It looks like much of the code is very well-written and should deliver very highly-performant-and asynchronous native applications.

For now though, C# async is looking mighty tasty. Can't wait for PDC to hear the rest of the story.

Here's a joke I just found:

"Knock, Knock"

"Who's there?"

....

.....

(very long pause)

..

..

"See-sharp!"

(But seriously, what is with the long initialisation delays in .NET programs? I thought the CLR was meant to cache JIT'd assemblies so that future application initialisation would be just as fast as a native executable).

2 minutes ago, Charles wrote

@Srikanth_t: Have you used IE9? Chrome is not faster.

Uhhhhhh, you sure about that (read all the pages)?

...and that's just scripting performance. What about the responsiveness of the UI? That's just as (if not more) important.

Oh, as an aside, C9 still has massive delays in page loading. When's that going to be fixed?

I use both browsers on a daily basis. There's performance differences, in both directions, but the differences aren't enough to matter. Most of this sounds like childish schoolyard bluster. I've not noticed a performance problem with any of the things mentioned, even in comparison to the supposedly "better" alternatives.

Performant code is quite important. Bing maps vs Google Maps is great example. While I do like Bing maps better for content, it is no where near as quick as Google Maps is.

Same thing for Skydrive (Office Live Webapps, whatever it is). Not only is it really clunky and requires way too many clicks, it is damn slow. Reload the page everytime I switch folders. Being at a Live@Edu school, no one wants to use Windows Live Groups or Live Skydrive applications at all. No one can figure out how to share crap. Horrible mistakes making bad interfaces that are slow.

Microsoft needs a performance czar that is * like. Make things damn quick.

IE9 and Windows 7 are pretty good attempts at making fast applications. Windows 7 still has some random slowdowns that really do not make sense.

26 minutes ago, Charles wrote

@W3bbo: Um, that's IE9 64-bit. My assumption is that it is not the same JS VM as IE9 32 bit. In fact, that must be the case.... In that graph, IE9 32 beats everything.

Apples to Oranges, 32 to 64 is.
C

You didn't read the whole article, you only read the first page and the single graph that was on there.

@Charles: FYI I just clicked marked as spam on your message, not sure how to un click it. Didn't mean to

@Charles:

http://news.ycombinator.com/item?id=1913315

Dead code should not be run by the JS interpreter period. If a node on the parse tree is determined as non-functional, it should be cut off immediately.

"By returning immediately out of the loop, Chrome's time drops by a factor of 12.1, whereas IE's stays pretty much constant."

If IE8 disable onResize() events like all other browsers, I am sure it will be blazing fast. A single resize of the browser will trigger at least 100 elements (DIVs) resize event in a typical HTML page. It will be 100xResizeEvenFiring slower than all other browsers, but, still, I would much prefer IE8 support it. It is sad my company needs to support all browsers, so, I ended up with extremly messy structure to trigger the event (does not support windows resize, only support very specific DIV resize). It is a half assed solution and very messy, but, that's what my company wants.

If it is my site, I would prefer simple clean code instead of that.

@Charles:

  I define code as being performant if it uses less memory and less cpu cycles to perform an activity. I say this with a view on battery life (call me an enviro-whacko if you want).

Have you used IE9? Chrome is not faster. Also, nobody forces managed code on you and it's a myth that managed code is slow...

 Honestly, I have not used IE9 but will do soon( once I can get some work out of the way ).  But IE8 has been a hog every which way.

I agree managed code doesn't mean slow and in some cases it could actually be faster.. try the following for example in managed and unmanaged....

class xyz{
  // stuff
};

xyz::xyz()
{
   // allocate some memory
}

xyz::~xyz()
{
 // de-allocate
}

MyFunc()
{
  loop()
  {
     xyz  myObj = new xyz();
     // do some stuff
     delete  myObj;
  }
}

 Managed code is faster above. The point I am trying to make is, code can be performant or non-performant REGARDLESS of the programming environment. It is the emphasis given by the developer (to perf) that makes the difference. I just get the feeling that devs have somehow gotten it in to their thinking that maintainable code means less performant code. Also there seems to be too much design patterns KoolAid drinking where we are layering libraries upon libraries. Obviously, there should be a proper balance struck between layering and not layering.

Now coming to IE9, from what I read so far, it seems to be relying on GPU for a lot of it's speed...  what does that do to the battery life ( assuming the code base makes it's way in to handhelds). It seems Opera is coming close to IE9 even without hardware acceleration.

The .NET VM (CLR) is super fast and its GC is one of the world's best. Now, WP7 does not employ the same GC (it can't... ARM "requires" that you use a non-generational GC. Yes, quotes for a reason around requires - it's a really, really hard technical problem that the WP7 team hasn't solved).

I see competitors with full aqua/glass effect enabled, and I see WinPh7 with rectangle buttons...and still the battery life is subpar.

So, be clear. You are talking about WP7 (which means Windows CE, the Compact Framework and a non-generational GC). XNA on the phone is pretty blazing given the environment. Silverlight is pretty fast, too.

If close-to-machine performance is your ultimate benchmark, then you know what language/tools/runtime you need to use

What are you you saying, exactly, again? .NET has to what? Be as fast as Java? Come on...

C

 Everytime I see any decent sized silverlight app..my machine goes > 40%. Again, the question if how many cpu cycles is the code eating up.

CPU usage isn't necessarily a great indicator of power usage though, an app which uses 100% of the CPU for 1 second may well use less power than something which uses just 10% but for 5 seconds. Memory usage also doesn't correspond to power consumption either.

Battery life should be an important metric for developers as more and more people work exclusively on laptops and mobile devices, however the best measurement is the actual impact on battery life rather than guessing by CPU or memory use.