Tag Archives: Performance

Taking on New Challenges: Joining the IE Team

How I Started

I’ve been into computers since I was a kid. The story is long, but I essentially started writing software in the 5th grade at North Elementary School in East Liverpool, Ohio. We had a quick introduction to computers. Our teacher discussed high-level and low-level languages and then introduced us to BASIC programming. I wrote my first program:

10PRINT “TOBY”
20GOTO 10
RUN

(Aside: For those that don’t know, I begrudgingly admit I went by “Toby” back in those days).

800xl[1]My eyes filled with wonder as my name scrolled down the screen. I immediately looked at the next instructions, and the next, and the next, and the next. My dad picked up an ATARI 800XL for the house. I spent many a full day at home working on that computer — painstakingly putting Microsoft ATARI BASIC and ATARI Assembler instructions from programming books and watching with wonder as the screen flashed exactly what I told it to do and the four voice, 3.5 octave sound screamed at me. I’ll spare you the details, but those were the beginnings of my fascination with computers. Some years later I had, for a number of reasons, stopped programming on the ATARI. When it was time to go to college, my parents got me a Packard Bell 486 DX2 66 computer. I went to college for Graphic Design – not computer science. However, when I found BASIC on the computer, I suddenly found myself hanging out with the C.S. folks more than my own classmates.

The Wonder of the Web

packardbell[1]After three semesters of college, I ran out of cash and my choice of Graphic Design over computer science made it hard for me to want to go back to college. I moved to Greenville, SC in 1994 and started playing with my Packard Bell. I mostly used it to talk on BBS’s and occasionally AOL when I could afford the time (for those of you that don’t know/remember back that far, you used to get charged by the minute for AOL use). I spent a bit of time writing small desktop applications with my copy of Visual Basic 3, patching software to get it to do what I wanted, or adding photos of myself inside my favorite games to my friends amazement. But I also started playing with HTML – something that had not yet standardized, but that I wanted to be a part of. I’ll never forget my first webpage. It had a picture of Alicia Silverstone on it – the “chick from that Aerosmith video”. The thing I liked about the web is that it combined my love for graphic design with my need for technical understanding.

I’ll again spare you the details and skip forward a few years. I was working for a consulting company called Metro Information Services as a contractor for AIMCO – at the time it was the largest property management REIT in the country. I worked on several web-based intranet applications in the 1999-2000 timeframe getting use something new called XML Data Islands, DHTML behaviors and something new called XMLHttpRequest. This allowed me to create applications that appeared more responsive and did work behind the scenes on users behalf. I fell in love with this technology with Internet Explorer and probably overused it. With just HTML and JavaScript, I felt back then that eventually most applications would become web-based with very little need for ActiveX or Java fillers. I knew that the server was still an important part too so I continued to work on enterprise middleware and database development. But I knew that the web – both server and client — was where I was meant to work.

Moving to Microsoft

Skipping forward to 2006, I had worked contract after contract, making a lot of money but starting to get bored and burned out. I was going to take a year off work and “play” with the technologies I loved most. Then Microsoft called. They had an opportunity to work with the teams that built ASP.NET and IIS. This seemed like the best opportunity so I took it. I joined as a Programming Writer for IIS. You could summarize this as simply a “documentation writer” position if you didn’t know any better. That said, I came to realize that this job required skills as both a great communicator and a great programmer. You needed to learn how to analyze API code that was written, and describe how to use it without any help. I loved my job when I first started it. However, the continued pressure to document every exposed method no matter how trivial it was also began to weigh heavily on me. I loved the web and this position seemed like the perfect position for me – till you find yourself writing documentation such as “The IAppHostSectionDefinition::Name Property Gets the name of the current configuration section definition.”

loginI had a growing desire to fix MSDN. As a developer, there were so many things that I felt I could help MSDN with, I thought I couldn’t go wrong. I loved working with the MSDN and TechNet teams. I helped redesign the home page based off of customer feedback, metrics we collected and the overall direction the company was heading. I started the MSDN News program which allowed us to aggregate content from various places inside and outside of the company and disseminate it across multiple locations. I designed and MSDN Insiders program. At every turn, however, I just felt like I was building someone else’s vision rather than making the impact I wanted to. I also, strangely enough, wasn’t getting to use the latest, greatest technology to build MSDN. I had a heavy desire to build HTML5 sites, mobile sites, and incorporate features like pinning. It’s not that I didn’t believe in what was being built, but my passions for it were not there.

Introduction to IE

UntitledI started diving into HTML5, CSS and JavaScript pretty heavily again. Inspired by the type of work that Rey Bango was doing, I wanted to reestablish my passion for the web. I began talking to people about this passion and paying more attention to what the community was saying about standards, development challenges, and of course, browsers. As I read more books I noticed that IE was rarely mentioned and if it was, it was in a bad light. Some of this was perception but some of it was reputation earned long-ago on the backs of still-lingering down-level versions of the product. I became angry when I saw a cartoon being passed around twitter. The cartoon, which many of you may have seen, was of three boys dressed in browser costumes. A Chrome-costumed boy had a Firefox-costumed boy in a headlock and they were clearly battling it out – each shouting the name of their product while holding a determined look on their face. In the corner was a baby-blue pajamad boy with a baby-blue helmet on. The helmet, of course, had an “e” on it to indicate Internet Explorer. This boy wasn’t battling at all. He was eating paste! This made me mad because I knew that the IE team was actually listening for feedback and had made considerable investment in battling back since IE6. I knew we still had our problems in IE, but certainly they didn’t deserve the “touched boy eating paste” image.

I sent a well-thought out email to the VP of IE and expressed my frustration with not only the cartoon, but the idea that we weren’t even considered a player for many people. I expected to get a pink slip for this “career-limiting email”. How often have you heard about someone telling a VP that their product needed work to be rewarded for it? Not often, in my experience. However, I was surprised to see an email come back from the VP fairly quickly. At the end of my email I asked “what can we, as employees, do to help with these problems?” The answer for this VP was pretty simple – “come and fix it.” At the VP’s request, I met with a man from IE. He listened to me and what I was passionate about and what I felt needed fixed. He asked me if I had worked with HTML5 canvas yet to which I told him I did not. He asked me to go play with it for a couple weeks or a month and let me know if I liked it and what I thought about working with it for a while. I wrote a few quick[1] demos[2] in a few days with HTML5 and shot them over to him. They weren’t great so I expected him to hate them. I hadn’t optimized my code. I wasn’t using standards. I wasn’t doing all the things someone interested in performance should do.

darkbookWe met again for coffee and he listed some of these things on the board as we chatted. At the end of the conversation he said “these could be your commitments.” Long story short, after a few more discussions I was given an offer to come join the IE performance team. I’ve got my work cut out for me. The people I met with in IE are top notch guys. They know their stuff inside and out. They know not only the code base and how it works, but how it should work. I’m told it’s going to take me about a year just to ramp up and be slightly effective. These guys have been working on the product for several years on average. I’m humbled to be able to work with them. I doubt I’ll ever be as smart as them, but I’m hoping to make my small impact on the product.

I was thankful to work with amazing people in MSDN. I’m thankful for this opportunity to work with great people again in IE. I’m excited about this move and the work ahead – something I desperately need to feel again about the work that I do. I’m excited about not only making IE better, but making the web better along the way for all of us.

My Request to Each of You

I’m going to be looking for feedback on IE. I don’t mind brutally honest feedback. If you’ve got it, I can take it. I really don’t know what work will look like in IE entirely or exactly what I’ll be able to do with most of the feedback – particularly so soon after joining the team. However, I’ll always be looking for feedback and will do my best to feed that back into the appropriate people inside the team.

Thanks for indulging me as I reminisced.

[Update] Just for clarity sake, I’m not sure how transparent I can be about what I’m doing or what the team is doing. You’ll never hear a new announcement about features or release dates or anything else coming from this blog. That’s really up to the team to communicate on official blogs. Just want to set expectations correctly.

Actualization and Collaboration

When I came to Microsoft over 5 years ago, I was lucky enough to find a side project to work on with some really smart people who, to this day, I consider to be my closest confidants at the company — Erik Porter and Ernie Booth. I can’t get into details entirely about the project except to say that many of our innovations and ideas can now be seen across the company in various forms such as the Kinect,  customizable 3D avatars in Xbox consoles, and some stuff in Bing maps that was added and later removed.  The project started off with Ernie and Erik discussing a project they had in mind. When I spoke with Erik about an idea I had, he felt there were similarities that could benefit and he introduced me to Ernie. We worked very well together as a trio. Ernie served as the optimist of the group, I the pessimist and Erik the neutral party. We worked late into the evenings talking about our ideas day in and day out. Shortly before submissions were due, we decided to put a Think Week paper together on our work. For those of you unfamiliar with Think Week., here is what Bill Gates says about the process:

Right now, I’m getting ready for Think Week. In May, I’ll go off for a week and read 100 or more papers from Microsoft employees that examine issues related to the company and the future of technology. I’ve been doing this for over 12 years. It used to be an all-paper process in which I was the only one doing the reading and commenting. Today the whole process is digital and open to the entire company.

We hastily put our research into an organized format, captured some screen shots, itterated a few times and prepared to submit our paper. As it happened, the submission deadline for the Think Week paper fell the day after there were massive wind storms and widespread power outages across the PacNW (including Microsoft campus) that made travel nearly impossible. We managed to find the one building with network access, huddled in the hallway and submitted our paper together. We hoped that we would at least get some comment of validation for our work and we walked away knowing that Mr. Gates would not be reading our papers for at least a few weeks.

Imagine my surprise when I got a voicemail from Erik one afternoon proclaiming that Mr. Gates had commented and I needed to read it and call him.

We were suprised that Mr. Gates read our paper and responded quite early — several weeks before his actual “Think Week”. He only did this on a few papers. His feedback was not only positive, it was glowingly positive and filled us with hope and confidence.

Ernie, Erik and I continued to collaborate and we used the positive feedback we had received from our hero to gain us meetings with several executives in the company. We were on a roll.  I was sent as a representative of Microsoft to a few standards meetings, conferences, etc. We continued pitching our ideas to several parts of the company. Xbox, Windows,  Silverlight/Expression,  Bing/Virtual Earth, Microsoft Games, Office and even our own HR department. We continued refining and adding to our pitch. We took internal courses that helped us learn how to better present our ideas. We learned how to use third parties who could act as our “insider” to help us refine and then pitch to our target audience. We gathered support from any place we could get it and even got some significant  funding for hardware, software and the like. Somewhere in the bowels of the data center lie three servers that were purchased for us.  We filed over a dozen patents in and around our ideas. We worked with Microsoft research and anyone who had even a remote relationship with what we had planned.

I can’t speak for Erik and Ernie but I was, as psychologists Goldstein and Maslow might say, self-actualized — firing on all cylinders, energized, pumped and primed for rapid advancement.

Flash forward to today. I am working at MSDN. I love the people here. I get along well with everyone. However, we all have our own goals and none of them are tied together in a meaningful , day-to-day way. We have no means to energize each other. Each of us have our own tasks. I have no one to bounce ideas off of and to receive their input which in turn will further accelerate another’s thinking.  This is what I’m missing. People who I can work with on a day-to-day basis and work on ideas, then capture them in a document.

I’ve been thinking about how to manufacture that feeling again. I want to collaborate with the community on how to work on my next generation of MSDN News. But I’m afraid even that may be difficult as I’m sure no one or two individuals could meet on a regular basis each day. I’d appreciate any thoughts from the community about how I can collaborate in a meaningful way.

Adding performance

Some of you may have found the title to this blog post as amusing as I do. Throughout my career, I’ve been called into many a meeting asking that I “add” performance to a complete or nearly-complete product. No matter how many scowls I got, I could never resist joking about just adding the IPerformance interface. “And, while you are at it, just add the IScalable one too”, I would quip. (OK, I know some of you are doing searches for these interfaces — don’t bother). Laugh as hard as I may, I’m embarrassed to say that I am trying to do this very thing now.

A few weeks ago, I started playing around with a small sample that shows off some of the fun features of IIS 7. As I started coding, I added more features to the sample. Scope creep is a no-no, but this was something I was doing on my own time so I didn’t have a problem with it. However, the sample got so large that I had to actually stop and design a public API to support it. By the time I was done, my “sample” had a set of providers, a common API, localization support, utilities, and most notably, performance issues.

Last year on my personal blog, I talked about “engineering for usability“. In that post, I declared that the simplest design is sometimes (and probably most often) the best approach. That said, performance should have been considered very early on, and the sample should have been kept simple. Performance, as many of you know, is not something you add as an afterthought. Starting my sample the way I did, I never considered code performance to be an issue.

Now I’m forced to decide: do I scale back my sample knowing full well that it doesn’t have a security model or provide easy extensibility, or do I redesign the sample with the current feature set and design for performance up front? I’m leaning toward the latter despite reciting “keep it simple, stupid” in my head over and over again.

Improving code performance

Recently, an old co-worker contacted me to ask me a question about code performance. Specifically, he was emitting IL from his code and had some questions about some of the opcode usage he witnessed when viewing the IL of some compiled assemblies.  The question was based on a simple application he wrote in C#, compiled, and disassembled.  He did this to see how the C# compiler produced IL and give him clues in how he should emit IL.  The function in question was as follows:


public object GetProp(string name)
{   if (name == “X”
   {    return this.X;
   }
   return null;
}

Now, the code obviously isn’t meant to do anything other than lend some insight into the IL.  Compiling to ‘debug’ the following IL was produced.

.method public hidebysig instance object
        GetProp(string name) cil managed
{
// Code size       35 (0x23)
.maxstack  2
.locals init ([0] object CS$1$0000,
          [1] bool CS$4$0001)
IL_0000:  nop
IL_0001:  ldarg.1
IL_0002:  ldstr      “X”
IL_0007:  call       bool [mscorlib]System.String::op_Equality(string, string)
IL_000c:  ldc.i4.0
IL_000d:  ceq
IL_000f:  stloc.1
IL_0010:  ldloc.1
IL_0011:  brtrue.s   IL_001d
IL_0013:  nop
IL_0014:  ldarg.0
IL_0015:  call       instance string class TestApp.TClass`1::get_X()
IL_001a:  stloc.0
IL_001b:  br.s       IL_0021
IL_001d:  ldnull
IL_001e:  stloc.0
IL_001f:  br.s       IL_0021
IL_0021:  ldloc.0
IL_0022:  ret
} // end of method TClass`1::GetProp

The question was, why was the stloc.1 and ldloc.1 needed after the ceq instruction at IL_000d (there are actually other issues in this small snippet, but I’ll focus on this particular one) . I, too, tried to resolve the issue and batted a few guesses around.  I proffered two ideas, and then ultimately suggested that the JIT compiler would likely be modifying this code anyway (particularly once it was recompiled in ‘release’ with optimization).

Still curious as to why the compiler produced the stloc and ldloc opcodes, I asked around internally until Vance set me straight with this blog post.

Introduction: What does ‘foreach’ actually do?
http://blogs.msdn.com/vancem/archive/2006/02/20/535807.aspx


Essentially, he states what I initially felt — that the JIT transformations on the IL are so dramatic, that you cannot judge an application’s performance based on the IL.  He also gives some great information on how to view your JITed code — with release optimizations and everything.  The other side to this is, that after further review, the inefficiencies of the IL were fixed in the optimized IL anyway once the code was set to ‘release’. 

Sometimes, it’s really easy to get side-tracked by these discussions in your quest for software glory.  I’m glad to know we have people like Vance around to set me straight when I do.