Designing for Performance by Martin Thompson

Ғылым және технология

What does it really mean to design software for high-performance? Performance is such a generic and misunderstood subject. In this talk the subject of software performance will be explored. We will focus on what is means to achieve sufficient response times, throughput, and scalability.
Once the theory is out of the way we will dig into how modern hardware works and what we need to know about abstractions mapping to our software designs. These abstractions are the key to the models our code represents. The author has not meet many abstraction layers he did not enjoyed violating. There is a good reason for this. So many of our abstractions are leaky or just plain wrong.
Martin Thompson is a Java Champion with over 2 decades of experience building complex and high-performance computing systems. He is most recently known for his work on Aeron and SBE. Previously at LMAX he was the co-founder and CTO when he created the Disruptor. Prior to LMAX Martin worked for Betfair, three different content companies wrestling with the world largest product catalogues, and was a lead on some of the most significant C++ and Java systems of the 1990s in the automotive and finance domains.
He blogs at mechanical-sympathy.blogspot.com, and can be found giving training courses on performance and concurrency when he is not cutting code to make systems better.
[IZL-4696]

Пікірлер: 8

  • @roshinivr123
    @roshinivr12314 күн бұрын

    What an amazing talk! I wish there were a great load of recent ones from Martin.

  • @allanwind295
    @allanwind29511 ай бұрын

    I always learn something from Martin's talks.

  • @10e999
    @10e99911 ай бұрын

    Great talk. I really liked the energy introduction. It's great to see software engineer understand that their code exist in the real world.

  • @sathiyanarayananagaraj4438
    @sathiyanarayananagaraj4438 Жыл бұрын

    Fantastic Talk

  • @niedowidek
    @niedowidek2 жыл бұрын

    36:18 Would be fantastic if these null checks were unnecessary but in huge, complicated, legacy system developed over almost 20 years (2005 are first commits to repository I'm thinking about), I never know where from null can come about. It's not only a thing of direct method calls which may be only in one, two or three other places. The null may be passed through several calls, from method to method. I've seen too many cases of NPE happening in production environment to leave possible null unattended. Clean code is fine but I prefer client who isn't screaming into his phone because users can't do something essential to their work all day (until hotfix comes up).

  • @10e999

    @10e999

    11 ай бұрын

    I'm with you on that one. Assert (design by contract) are a live saver

  • @yongkeekwon6790
    @yongkeekwon67904 жыл бұрын

    fantastic talk!

  • @mosheleland5104

    @mosheleland5104

    3 жыл бұрын

    InstaBlaster...

Келесі