Tech Off Thread

10 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Optimization

Back to Forum: Tech Off
  • User profile image
    exoteric

    JoeD on proper and improper optimization.

     

    He mentions many things. In/appropriate choice of data structure (linked vs arrayed), in/efficient techniques (LINQ to Objects vs in-place destructive array updates), unstated contracts (possibly slow lookup methods without type-level contracts, like lookup: T vs lookup: Task<T>), IO, and so on.

     

    The 'premature optimization is evil' myth 

     

    In the case of LINQ to Objects (a pleasant pastime of mine), it's sad to see that at least the recursive iteration pattern has still not been optimized for in some of the VS compilers; I don't know about Mono. But that just means that it's mostly appropriate in limited application-level scenarios (at least for practical applications).

  • User profile image
    Dr Herbie

    A great example of objectivity being bias by the area in which a programmer generally works.  JoeD work at the OS level, so optimisation is more important than writing business applications.

     

    Our customers would rather have a slow, functional version tomorrow, than a fast functional version next week.  If we can improve the speed after the initial release that's great, but they'd rather have the functionality now, thank's.  Speed is nice, but is costs more when you're paying for expensive customisations by the hour.

     

     

    Herbie

     

     

     

  • User profile image
    TommyCarlier

    Dr Herbie said:

    A great example of objectivity being bias by the area in which a programmer generally works.  JoeD work at the OS level, so optimisation is more important than writing business applications.

     

    Our customers would rather have a slow, functional version tomorrow, than a fast functional version next week.  If we can improve the speed after the initial release that's great, but they'd rather have the functionality now, thank's.  Speed is nice, but is costs more when you're paying for expensive customisations by the hour.

     

     

    Herbie

     

     

     

    If you develop for a wider audience (like a web application for consumers), slowness will have a negative impact on the perceived quality of your application. Like you said, it all depends on what you're developing and for whom.

  • User profile image
    Dr Herbie

    TommyCarlier said:
    Dr Herbie said:
    *snip*

    If you develop for a wider audience (like a web application for consumers), slowness will have a negative impact on the perceived quality of your application. Like you said, it all depends on what you're developing and for whom.

    Yes, should have the law 'Generalisations about optimisation are the root of all evil' Big Smile

     

    Herbie

     

  • User profile image
    exoteric

    Dr Herbie said:

    A great example of objectivity being bias by the area in which a programmer generally works.  JoeD work at the OS level, so optimisation is more important than writing business applications.

     

    Our customers would rather have a slow, functional version tomorrow, than a fast functional version next week.  If we can improve the speed after the initial release that's great, but they'd rather have the functionality now, thank's.  Speed is nice, but is costs more when you're paying for expensive customisations by the hour.

     

     

    Herbie

     

     

     

    I agree with your point about bias.

     

    Also, often abstraction is at odds with performance, not fundamentally so but in terms of what level of sophistication the language compiler is at, and when these odds collide, I prefer abstraction and correctness over performance. Unfortunately one often has to choose between the two. One place where performance matters less is in testing. I use LINQ to Objects and LINQ to SQL a lot in real-world test-case development (not just hobby projects). And it has paid off a lot already. It would be great if Microsoft Research was more involved in compiler optimizations for languages like C#, helping building the main VS compilers, bringing down the cost of using in-memory query abstractions.

     

    Joe does have a good point about thinking carefully about every line of code. Still, there's a difference between building platforms and building applications. Platforms impact applications. Applications don't impact other applications, at least not to the same degree. When building platforms for thousands of applications and tens or hundreds of millions of people, you really have to get your act together. One would also imagine applications have less tolerance for cost (getting things right) then platform development.

     

    As a "user", what never seizes to annoy me about applications, and this is true for many major Microsoft applications as well, for example Outlook and Office Communicator to name two, is the stalling of the UI thread. The application becomes unresponsive as the application window turns ghostly white. That kind of lag directly impacts user perception of application quality. Not to moralize about it, since mainstream tools for dealing with asynchrony have only recently started to become comfortable, courtesy of people like Joe.

  • User profile image
    Charles

    "And lastly, the productivity and safety gains of managed code, thanks to nice abstractions, type- and memory-safety, and automatic memory management, do not have to come at the expense of performance. Indeed this is a stereotype that performance conscious programmers are in a position to break down. All you need to do is slow down and be thoughtful about each and every line of code you write. Remember, programming is as much engineering as it is an art. Measure, measure, measure; and, of course, be thoughtful, intentional, and responsible in crafting beautiful and performant code."

     

    Yes, Joe. You've been spending some quality time with Rico Mariani, eh? Smiley

    C

  • User profile image
    davewill

    The general theme is that we need to make practical decisions as we code and given the size of software projects we need to use whatever mechanisms might be available to keep a higher understanding of what is going on (task list t).

  • User profile image
    vesuvius

    I think you have to accept that in the world that Joe lives in, then optimisation is a necessity, however early or late in the cycle.

     

    If you work on certain (not all) products at Microsoft, then it is important that performance is Key, as those libraries will be used by all manner of developers, some even in performance centred applications.

     

    If however it is a business application, a blog, or something with a user base of less that 100 at any one time, then features and functionality are more important (especially for new applications).

     

    I typically build a UI that is single threaded in new applications, then use the parallel extensions and multi-threading once the customer is happy that we are near feature complete. It is better to have 100 modules with 30 that freeze, or are slow, than have an application with 20 highly optimised modules that take several months to acheive.

     

    Developing is about learning to live with imperfection a lot of the time (unless you work on the concurrency team)

  • User profile image
    cheong

    vesuvius said:

    I think you have to accept that in the world that Joe lives in, then optimisation is a necessity, however early or late in the cycle.

     

    If you work on certain (not all) products at Microsoft, then it is important that performance is Key, as those libraries will be used by all manner of developers, some even in performance centred applications.

     

    If however it is a business application, a blog, or something with a user base of less that 100 at any one time, then features and functionality are more important (especially for new applications).

     

    I typically build a UI that is single threaded in new applications, then use the parallel extensions and multi-threading once the customer is happy that we are near feature complete. It is better to have 100 modules with 30 that freeze, or are slow, than have an application with 20 highly optimised modules that take several months to acheive.

     

    Developing is about learning to live with imperfection a lot of the time (unless you work on the concurrency team)

    > If you work on certain (not all) products at Microsoft, then it is important that performance is Key, as those libraries will be used by all manner of developers, some even in performance centred applications.

     

    This reminds me of Larry's story regarding unexpected consequence of a non-optimized API call that's not supposed to be called frequently. Smiley

    Recent Achievement unlocked: Code Avenger Tier 4/6: You see dead program. A lot!
    Last modified
  • User profile image
    exoteric

    , vesuvius wrote

    Developing is about learning to live with imperfection a lot of the time (unless you work on the concurrency team)

    It's something we all hate but all have to live with (well, most of us).

    Speaking of performance, I wonder if we can get Charles to talk to the C# and/or VB design teams about what new features they've been working on and whether some of them are already baked enough to be in the final specs.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.