What’s wrong with virtual methods called through an interface.

What’s wrong with virtual methods called through an interface.
Or why is it so slow and how to make it faster.

Stefan Glienke Something we discussed some time ago :-)
http://andy.jgknet.de/blog/2016/05/whats-wrong-with-virtual-methods-called-through-an-interface/

Comments

  1. Eric Grange "While faster interface calls would certainly be nice, most of the time, it will be irrelevant unless you're doing those calls in tight loops to functions whose sole job is to return an integer..."

    Doesn't this describe numerical-oriented filter/map/reduce operations?

    ReplyDelete
  2. David Heffernan "Delphi is presumably still one pass."

    This was part of an argument I was involved in on the EMBT forum a few years ago. I was told I was wrong to call it a single pass compiler by some, and then Allen Bauer showed up to defend Delphi by explaining that parts of the process aren't single pass. I stated "Then let's call it a 1.5 pass compiler then, because what you've described isn't a multi-pass compiler". :-) It appears that it's essentially still single pass other than a few small optimizations.

    >If dcc32 were to work harder to optimise code then
    >surely it would be slower.

    I love the way Apple handled this. Swift comes with what they call a "playground", an interpreted version of Swift. You can rapidly prototype code, explore ideas in real time, etc., just like many dynamically typed languages offer. However, you can also compile your code.

    I think it would be great if there were an interpreted version of Delphi (we've seen it done, obviously with some language changes, with DWScript), so the compile time would be zero. You could test and debug and prototype your code with that. When it was time to deliver/ship/deploy your code, you could compile it, and it wouldn't matter if it made 40 passes through the code because you only have to compile it once. You'd really have the best of both worlds.

    ReplyDelete

Post a Comment