Re: benchmarks? java vs .net (sin and cos)

Discussion in 'C++' started by Jon Skeet [C# MVP], Jun 4, 2008.

  1. Razii <> wrote:
    > On Wed, 04 Jun 2008 19:29:35 +0100, Jon Harrop <>
    > wrote:
    >
    > >For another subjection notion of "correct" that also has no practical
    > >relevance, yes.

    >
    > Why can't you post C# version that uses standard library and is not
    > slower? Perhaps that's because it's not possible?


    Out of interest, what happens in your version of the test if you avoid
    the deprecated StreamTokenizerConstructor? Force Java to actually deal
    with text as text (which is why the constructor taking Stream is
    deprecated) and see how the results fare.

    On my box it makes Java slower than .NET - but YMMV.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #1
    1. Advertising

  2. Razii <> wrote:
    > On Wed, 4 Jun 2008 20:01:54 +0100, Jon Skeet [C# MVP]
    > <> wrote:
    >
    > >Out of interest, what happens in your version of the test if you avoid
    > >the deprecated StreamTokenizerConstructor? Force Java to actually deal
    > >with text as text (which is why the constructor taking Stream is
    > >deprecated) and see how the results fare.


    <snip results: Java=4.2s->5.4s; .NET=6.4s>

    Interesting - on my box it *halves* the speed of the Java version, to
    *way* slower than the .NET version.

    What happens if you run it not under Cygwin? (Now that it's just a big
    file, it's very easy to see the elapsed time without using Cygwin.)

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #2
    1. Advertising

  3. Razii <> wrote:
    > On Wed, 04 Jun 2008 20:34:59 +0100, Jon Harrop <>
    > wrote:
    >
    > >You are still timing Cygwin's implementation of Unix pipes which has nothing
    > >to do with anything.

    >
    > I am still waiting for you to verify and demonstrate it has any
    > effect.


    You're the one in the best position to test this, as you're the one
    with Cygwin installed.

    Run the benchmark I provided earlier both in Cygwin and from a plain
    Windows prompt (with java SumCol < sumcol-large.txt and
    SumCol < sumcol-large.txt, as well as java SumCol sumcol-large.txt and
    SumCol sumcol-large.txt) and present the results.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #3
  4. Razii <> wrote:

    <snip>

    > sumcol < sum.txt
    > 10500000
    > Time: 6821
    >
    > java -server sumcol < sum.txt (Java)
    > 10500000
    > Time: 5231
    >
    > Blah no difference. Enough with Cygwin nonense.


    Fair enough. One interesting point I've found is that if you tell
    InputStreamReader to use UTF-8, it works *much* more slowly than if you
    use the default encoding (on my box, anyway).

    You still haven't posted the results of accessing the file directly,
    however - on my box they showed Java and .NET neck and neck. How about
    on yours? If they show the same results, then we can conclude that .NET
    is indeed slower at reading console input than Java - which is
    interesting, but certainly nothing like your wide-scale generalisation
    that "C# is slower than Java".

    (Also note that your results are nowhere near the "2x slower" that you
    were previously posting about sumcol - I suspect that was due to the
    overhead of starting up .NET being slightly greater than the overhead
    of starting up Java for this test. Again, interesting to know but not
    terribly relevant to real world applications which typically run for
    rather more than a few milliseconds.)

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #4
  5. Jon Skeet [C# MVP] wrote:
    > Razii <> wrote:
    >
    > <snip>
    >
    >> sumcol < sum.txt
    >> 10500000
    >> Time: 6821
    >>
    >> java -server sumcol < sum.txt (Java)
    >> 10500000
    >> Time: 5231
    >>
    >> Blah no difference. Enough with Cygwin nonense.

    >
    > Fair enough. One interesting point I've found is that if you tell
    > InputStreamReader to use UTF-8, it works *much* more slowly than if you
    > use the default encoding (on my box, anyway).


    That isn't too surprising as you are most likely using a single byte
    encoding by default. Decoding these is rather trivial.

    Mark Thornton
    Mark Thornton, Jun 4, 2008
    #5
  6. Mark Thornton <> wrote:
    > > Fair enough. One interesting point I've found is that if you tell
    > > InputStreamReader to use UTF-8, it works *much* more slowly than if you
    > > use the default encoding (on my box, anyway).

    >
    > That isn't too surprising as you are most likely using a single byte
    > encoding by default. Decoding these is rather trivial.


    Indeed - although decoding UTF-8 is fairly easy when all the characters
    happen to be ASCII. Still an extra branch, mind you.

    I should have posted what surprised me: forcing .NET to use a single
    byte encoding when reading the file doesn't improve the speed by much.
    Trying to change the encoding for stdin with .NET is slightly trickier
    - instead of using Console.In, you need to use
    Console.OpenStandardInput to get a stream, then wrap that.

    However, your post prompted me to do precisely that - and funnily
    enough, that then means the reader via stdin is roughly as fast as
    reading directly from the file; significantly faster than using
    Console.In. I wonder what Console.In is doing to slow it down...

    (Another nail in the coffin of the claim that ".NET is twice as slow as
    Java" though, and a handy thing to know should I ever be in the
    unlikely situation of dealing with large amounts of data piped through
    stdin.)

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #6
  7. Jon Skeet [C# MVP] wrote:
    > Mark Thornton <> wrote:
    >>> Fair enough. One interesting point I've found is that if you tell

    >
    > However, your post prompted me to do precisely that - and funnily
    > enough, that then means the reader via stdin is roughly as fast as
    > reading directly from the file; significantly faster than using
    > Console.In. I wonder what Console.In is doing to slow it down...


    Possibly some form of cooked mode --- synchronization with Console.out.

    >
    > (Another nail in the coffin of the claim that ".NET is twice as slow as
    > Java" though,

    I don't see much in these benchmarks of the sort of code where the more
    mature HotSpot JIT could be expected to outshine .NET.

    Mark Thornton
    Mark Thornton, Jun 4, 2008
    #7
  8. Mark Thornton <> wrote:
    > > (Another nail in the coffin of the claim that ".NET is twice as slow as
    > > Java" though,


    > I don't see much in these benchmarks of the sort of code where the more
    > mature HotSpot JIT could be expected to outshine .NET.


    Indeed. As I said before, it's pretty easy to construct code where Java
    *does* outperform C#:

    VirtualTest.cs:
    using System;
    using System.Diagnostics;

    public class VirtualTest
    {
    const int Iterations = 1000000000;

    static void Main()
    {
    Stopwatch sw = Stopwatch.StartNew();
    VirtualTest t = new VirtualTest();
    int sum=0;
    for (int i=0; i < Iterations; i++)
    {
    sum += t.GetNumber();
    }
    Console.WriteLine(sw.ElapsedMilliseconds);
    }

    public virtual int GetNumber()
    {
    return 1;
    }
    }

    VirtualTest.java:
    public class VirtualTest
    {
    private static final int Iterations = 1000000000;

    public static void main(String[] args)
    {
    long start = System.currentTimeMillis();
    VirtualTest t = new VirtualTest();
    int sum=0;
    for (int i=0; i < Iterations; i++)
    {
    sum += t.GetNumber();
    }
    long end = System.currentTimeMillis();
    System.out.println(end-start);
    }

    public int GetNumber()
    {
    return 1;
    }
    }

    As it is, Java outperforms .NET (on my box) by about 3:1.
    Making GetNumber non-virtual, and .NET outperforms Java (on my box)
    about about 2:1.

    Pointless benchmark, of course, other than to show the inlining
    capabilities of Hotspot in the face of a virtual method which hasn't
    been overridden.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #8
  9. Razii <> wrote:
    > On Wed, 4 Jun 2008 22:21:31 +0100, Jon Skeet [C# MVP]
    > <> wrote:
    >
    > >(Another nail in the coffin of the claim that ".NET is twice as slow as
    > >Java" though, and a handy thing to know should I ever be in the
    > >unlikely situation of dealing with large amounts of data piped through
    > >stdin.)

    >
    > It's is much slower if using
    >
    > StreamTokenizer lineTokenizer = new StreamTokenizer(System.in);


    That was the version I originally had in Java though - and on my box
    that runs at about the same speed as the C# version using
    Console.OpenStandardInput() instead of Console.In.

    > What about binarytrees?
    >
    > http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=csharp&id=0
    > http://shootout.alioth.debian.org/gp4/benchmark.php?test=binarytrees&lang=javaxx&id=2


    I haven't looked at it yet - one step at a time. Let's try to conclude
    sumcol before moving on.

    You still haven't posted your results when loading files rather than
    reading via the console.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #9
  10. Razii <> wrote:
    > On Wed, 4 Jun 2008 23:03:59 +0100, Jon Skeet [C# MVP]
    > <> wrote:
    >
    > >You still haven't posted your results when loading files rather than
    > >reading via the console.

    >
    > Changing the lines to :
    >
    > BufferedInputStream in = new BufferedInputStream (new FileInputStream
    > ("sum.txt"));
    >
    > StreamTokenizer lineTokenizer = new StreamTokenizer(in);
    >
    > I get 4.519s which is slightly slower than using System.in: 4.224s


    That's changing the Java code. Now what about the C# code - and is that
    with the big file, or the original benchmark way of creating thousands
    of processes?

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 4, 2008
    #10
  11. Razii <> wrote:
    > On Wed, 4 Jun 2008 23:25:27 +0100, Jon Skeet [C# MVP]
    > <> wrote:
    >
    > >That's changing the Java code. Now what about the C# code - and is that
    > >with the big file, or the original benchmark way of creating thousands
    > >of processes?

    >
    > The original benchmark uses this file
    >
    > http://shootout.alioth.debian.org/download/sumcol-input.txt
    >
    > made 21,000 times bigger. Basically, concatenate the above file 21,000
    > times, and you have the same file that I and shootout site do.
    >
    > As for C# using file, post the changes.


    I did, early yesterday evening. I posted both a Java *and* a C# program
    which allowed you to either pipe input to the program *or* provide a
    filename.

    I also posted the results of running said code - C# was slower than
    Java when reading from stdin (at the time using Console.In - using
    OpenStandardInput narrows the gap) and about the same as Java when
    reading directly from a file.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 5, 2008
    #11
  12. Jon Harrop <> wrote:
    > Jon Skeet [C# MVP] wrote:
    > > Mark Thornton <> wrote:
    > >> > (Another nail in the coffin of the claim that ".NET is twice as slow as
    > >> > Java" though,
    > >> I don't see much in these benchmarks of the sort of code where the more
    > >> mature HotSpot JIT could be expected to outshine .NET.

    > >
    > > Indeed. As I said before, it's pretty easy to construct code where Java
    > > *does* outperform C#:
    > > ...
    > > As it is, Java outperforms .NET...

    >
    > That is Java outperforming C#, not .NET.


    No, it's Java outperforming .NET calling a virtual method. It has
    nothing to do with the code that the IL is generated in: if you have a
    virtual method which isn't overridden, the .NET CLR will not inline
    calls to it. The Hotspot VM will inline it until it first sees the
    method being overridden. The difference here is in the jitting model,
    not in the language.

    Try it in F#, ensuring that the method is virtual and actually called
    each time (consider that the method might be one which has side-
    effects). I can't see how it would possibly have a different result.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 5, 2008
    #12
  13. Jon Skeet [C# MVP]

    Barry Kelly Guest

    Jon Harrop wrote:

    > Jon Skeet [C# MVP] wrote:
    > > Jon Harrop <> wrote:
    > >> That is Java outperforming C#, not .NET.

    > >
    > > No, it's Java outperforming .NET calling a virtual method. It has
    > > nothing to do with the code that the IL is generated in: if you have a
    > > virtual method which isn't overridden, the .NET CLR will not inline
    > > calls to it. The Hotspot VM will inline it until it first sees the
    > > method being overridden. The difference here is in the jitting model,
    > > not in the language.
    > >
    > > Try it in F#, ensuring that the method is virtual and actually called
    > > each time (consider that the method might be one which has side-
    > > effects). I can't see how it would possibly have a different result.

    >
    > This optimization can obviously be done statically by the compiler.


    No - this optimization cannot be done statically for runtimes that
    support dynamic code loading, as the CLR and JVM do. If the compiler
    tries to replace 'callvirt' with 'call', the assembly will no longer be
    verifiable, and if the assembly is dynamically loaded into the context
    of another application, the virtual call semantics will be violated.

    For example:

    ---8<---
    using System;

    public class B
    {
    public virtual void M()
    {
    Console.WriteLine("Hello from B");
    }
    }

    public class App
    {
    static void Main()
    {
    CallM(new B());
    }

    public static void CallM(B instance)
    {
    instance.M();
    }
    }
    --->8---

    Compile this App.cs to App.exe, then disassemble with:

    ildasm App.exe /out:App.il

    Then edit App.il so that CallM is written thusly, applying the
    "optimization":

    ---8<---
    .method public hidebysig static void CallM(class B 'instance') cil
    managed
    {
    // Code size 9 (0x9)
    .maxstack 8
    IL_0000: nop
    IL_0001: ldarg.0
    IL_0002: call instance void B::M()
    // (above was 'callvirt')
    IL_0007: nop
    IL_0008: ret
    } // end of method App::CallM
    --->8---

    Assemble with:

    ilasm App.il

    Verify with:

    peverify App.exe

    Observe error:

    ---8<---
    Microsoft (R) .NET Framework PE Verifier. Version 3.5.21022.8
    Copyright (c) Microsoft Corporation. All rights reserved.

    [IL]: Error: [c:\proj\cli-callvirt\App.exe : App::CallM][offset
    0x00000002] The 'this' parameter to the call must be the calling
    method's 'this' parameter.
    1 Error Verifying App.exe
    --->8---

    For a concrete example of virtual method call semantic violation,
    consider a second application, App2.cs:

    ---8<---
    using System;

    public class D : B
    {
    public override void M()
    {
    Console.WriteLine("Hello from D!");
    }
    }

    class App2
    {
    static void Main()
    {
    App.CallM(new D());
    }
    }
    --->8---

    Compile this with:

    csc App2.cs /r:App.exe

    Run App2.exe when App.exe is the version assembled from App.il modified
    to use call instead of callvirt, and observe:

    ---8<---
    Hello from B
    --->8---

    Recompile the original App.cs from source, then run App2, and observe:

    ---8<---
    Hello from D!
    --->8---

    - the "obvious optimization" has broken virtual method call semantics.

    Implementing the "optimization" for strictly private classes is not
    useful either, as reflection with appropriate permissions, along with
    runtime code generation, can see through such visibility constraints.

    -- Barry

    --
    http://barrkel.blogspot.com/
    Barry Kelly, Jun 5, 2008
    #13
  14. Jon Skeet [C# MVP] wrote:
    > Mark Thornton <> wrote:
    >>> (Another nail in the coffin of the claim that ".NET is twice as slow as
    >>> Java" though,

    >
    >> I don't see much in these benchmarks of the sort of code where the more
    >> mature HotSpot JIT could be expected to outshine .NET.

    >
    > As it is, Java outperforms .NET (on my box) by about 3:1.
    > Making GetNumber non-virtual, and .NET outperforms Java (on my box)
    > about about 2:1.
    >
    > Pointless benchmark, of course, other than to show the inlining
    > capabilities of Hotspot in the face of a virtual method which hasn't
    > been overridden.
    >


    It does have real relevance. I have classes with multiple
    implementations, but quite frequently a given process will only use one
    of the possible implementations.

    Mark Thornton
    Mark Thornton, Jun 5, 2008
    #14
  15. Jon Harrop <> wrote:
    > >> This optimization can obviously be done statically by the compiler.

    > >
    > > No - this optimization cannot be done statically for runtimes that
    > > support dynamic code loading, as the CLR and JVM do...

    >
    > I just posted a working example where the optimization is done, so it is
    > clearly not impossible. The only question is (subjectively) was my code
    > equivalent.


    Is your method virtual, and called virtually? If not, then it's not
    equivalent. If it is, then the JIT can't inline it.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 5, 2008
    #15
  16. Mark Thornton <> wrote:
    > > Pointless benchmark, of course, other than to show the inlining
    > > capabilities of Hotspot in the face of a virtual method which hasn't
    > > been overridden.

    >
    > It does have real relevance. I have classes with multiple
    > implementations, but quite frequently a given process will only use one
    > of the possible implementations.


    Fair enough - but it's only significant if:
    a) the implementation is small enough to inline
    b) the method call would be a significant hit, i.e. it's a bottleneck
    in the app

    Obviously I can't speak for your experience, but mine is certainly that
    the two don't come together very often. More likely in the scientific
    world than the business world, I suspect.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 5, 2008
    #16
  17. Jon Skeet [C# MVP] wrote:
    > Mark Thornton <> wrote:
    >>> Pointless benchmark, of course, other than to show the inlining
    >>> capabilities of Hotspot in the face of a virtual method which hasn't
    >>> been overridden.

    >> It does have real relevance. I have classes with multiple
    >> implementations, but quite frequently a given process will only use one
    >> of the possible implementations.

    >
    > Fair enough - but it's only significant if:
    > a) the implementation is small enough to inline
    > b) the method call would be a significant hit, i.e. it's a bottleneck
    > in the app
    >
    > Obviously I can't speak for your experience, but mine is certainly that
    > the two don't come together very often. More likely in the scientific
    > world than the business world, I suspect.
    >


    I do vehicle routing algorithms, so although the application is sold to
    businesses, its core is more scientific/mathematical in nature. Using
    100% CPU is routine. I'm working on achieving that for multi core
    machines as well.

    Mark Thornton
    Mark Thornton, Jun 5, 2008
    #17
  18. Jon Skeet [C# MVP]

    Barry Kelly Guest

    Jon Harrop wrote:

    > Jon Skeet [C# MVP] wrote:
    > > Jon Harrop <> wrote:
    > >> That is Java outperforming C#, not .NET.

    > >
    > > No, it's Java outperforming .NET calling a virtual method. It has
    > > nothing to do with the code that the IL is generated in: if you have a
    > > virtual method which isn't overridden, the .NET CLR will not inline
    > > calls to it. The Hotspot VM will inline it until it first sees the
    > > method being overridden. The difference here is in the jitting model,
    > > not in the language.
    > >
    > > Try it in F#, ensuring that the method is virtual and actually called
    > > each time (consider that the method might be one which has side-
    > > effects). I can't see how it would possibly have a different result.

    >
    > This optimization can obviously be done statically by the compiler. There is
    > no assurance that F# will also fail to optimize this, particularly if you
    > write a functional equivalent:


    We're not talking about "functional equivalents". We're talking about
    virtual methods that are callable by third-party code written in any CLR
    language, i.e. methods for which a MethodInfo instance can be obtained
    from reflection, and for which MethodInfo.IsVirtual returns true and
    MethodInfo.IsFinal returns false.

    Any code in F# or any other language which doesn't compile to something
    that can be loaded in MethodInfo form via System.Reflection doesn't
    apply, because it simply isn't a virtual method.

    -- Barry

    --
    http://barrkel.blogspot.com/
    Barry Kelly, Jun 5, 2008
    #18
  19. Jon Skeet [C# MVP]

    Barry Kelly Guest

    Jon Skeet wrote:

    > Mark Thornton <> wrote:
    > > > Pointless benchmark, of course, other than to show the inlining
    > > > capabilities of Hotspot in the face of a virtual method which hasn't
    > > > been overridden.

    > >
    > > It does have real relevance. I have classes with multiple
    > > implementations, but quite frequently a given process will only use one
    > > of the possible implementations.

    >
    > Fair enough - but it's only significant if:
    > a) the implementation is small enough to inline
    > b) the method call would be a significant hit, i.e. it's a bottleneck
    > in the app
    >
    > Obviously I can't speak for your experience, but mine is certainly that
    > the two don't come together very often. More likely in the scientific
    > world than the business world, I suspect.


    FWIW, when one adopts the test-first style of development, the ability
    to create mocks (whether by inheritance or the proxy capabilities of the
    CLR/etc.) and use dependency injection frameworks (inversion of control
    pattern) to abstract away your dependencies becomes very important.

    It's then that the ability of the runtime to optimize virtual method
    calls to statically dispatched calls becomes a lot more important,
    because:

    1) Usually, the only point of a method being virtual is so that it can
    easily be mocked

    2) Usually, when running "for real" and not for test, only a single
    implementation of that method will be loaded into the runtime.

    I wouldn't discard the utility of the virtual -> static call
    optimization so trivially.

    Of course, some kind of more direct language or runtime support for
    mocking and / or inversion of control might be a better solution than
    willy-nilly making every method virtual, as that has other, more severe
    repercussions for designability and testability - classes with virtual
    methods being a lot harder to test due to the extra code paths.

    -- Barry

    --
    http://barrkel.blogspot.com/
    Barry Kelly, Jun 5, 2008
    #19
  20. Barry Kelly <> wrote:
    > > Obviously I can't speak for your experience, but mine is certainly that
    > > the two don't come together very often. More likely in the scientific
    > > world than the business world, I suspect.

    >
    > FWIW, when one adopts the test-first style of development, the ability
    > to create mocks (whether by inheritance or the proxy capabilities of the
    > CLR/etc.) and use dependency injection frameworks (inversion of control
    > pattern) to abstract away your dependencies becomes very important.


    True.

    > It's then that the ability of the runtime to optimize virtual method
    > calls to statically dispatched calls becomes a lot more important,
    > because:
    >
    > 1) Usually, the only point of a method being virtual is so that it can
    > easily be mocked
    >
    > 2) Usually, when running "for real" and not for test, only a single
    > implementation of that method will be loaded into the runtime.


    Absolutely. I don't dispute that at all - I just wonder how often those
    virtual methods are both small enough to be inlined *and* critical for
    performance.

    I'm sure there are some cases where it makes a really huge difference -
    but I suspect it makes a *slight* difference to a far greater
    proportion of apps.

    > I wouldn't discard the utility of the virtual -> static call
    > optimization so trivially.


    One reason it's so important in Java of course is that methods are
    virtual by default. C# (and VB.NET, I believe) methods are non-virtual
    by default. The defaults wouldn't make a difference if every developer
    diligently thought about whether or not to make a method virtual every
    time they wrote it - but of course, few people (myself *not* included)
    are that diligent.

    > Of course, some kind of more direct language or runtime support for
    > mocking and / or inversion of control might be a better solution than
    > willy-nilly making every method virtual, as that has other, more severe
    > repercussions for designability and testability - classes with virtual
    > methods being a lot harder to test due to the extra code paths.


    Well, just because an interface has a virtual method doesn't mean it
    has to be virtual in the implementing class. But yes, inheritence of
    implementation certainly has a design cost associated with it.

    --
    Jon Skeet - <>
    Web site: http://www.pobox.com/~skeet
    Blog: http://www.msmvps.com/jon.skeet
    C# in Depth: http://csharpindepth.com
    Jon Skeet [C# MVP], Jun 5, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Thornton
    Replies:
    3
    Views:
    358
    Arne Vajhøj
    Jun 9, 2008
  2. Mark Thornton
    Replies:
    3
    Views:
    478
    Arne Vajhøj
    Jun 9, 2008
  3. Patricia Shanahan

    Re: benchmarks? java vs .net (sin and cos)

    Patricia Shanahan, Jun 4, 2008, in forum: Java
    Replies:
    25
    Views:
    786
    Arne Vajhøj
    Jun 9, 2008
  4. Patricia Shanahan

    Re: benchmarks? java vs .net (sin and cos)

    Patricia Shanahan, Jun 4, 2008, in forum: C++
    Replies:
    24
    Views:
    813
    Arne Vajhøj
    Jun 9, 2008
  5. Jon Skeet [C# MVP]

    Re: benchmarks? java vs .net (sin and cos)

    Jon Skeet [C# MVP], Jun 4, 2008, in forum: Java
    Replies:
    33
    Views:
    825
    Arne Vajhøj
    Jun 17, 2008
Loading...

Share This Page