Managed-Code Bloat

Discussion in 'Java' started by Lawrence D'Oliveiro, Jun 6, 2011.

  1. Came across this item
    <http://www.itwriting.com/blog/3385-lessons-from-evernotes-flight-from-net.html>
    about how Evernote for Windows abandoned WPF and Dotnet when moving from
    version 3.5 to 4.0, with the result that

    On our test hardware, Evernote 4 starts five times faster, and uses half
    the memory of Evernote 3.5.

    The whole managed-code/auto-garbage-collected concept may really appeal to
    corporate code-cutter types, but I think it has real trouble in the mass
    market.
     
    Lawrence D'Oliveiro, Jun 6, 2011
    #1
    1. Advertising

  2. On 11-06-06 03:47 AM, Lawrence D'Oliveiro wrote:
    > Came across this item
    > <http://www.itwriting.com/blog/3385-lessons-from-evernotes-flight-from-net.html>
    > about how Evernote for Windows abandoned WPF and Dotnet when moving from
    > version 3.5 to 4.0, with the result that
    >
    > On our test hardware, Evernote 4 starts five times faster, and uses half
    > the memory of Evernote 3.5.
    >
    > The whole managed-code/auto-garbage-collected concept may really appeal to
    > corporate code-cutter types, but I think it has real trouble in the mass
    > market.


    Did you read the whole article? Right at the end the author says:

    "The development team lacks the resources to build equivalent
    functionality in native code.

    "The last point is important. Maybe a hotshot team of C/C++ developers
    could make a better job, but if you don’t have such a team or the money
    to hire it, it is not so relevant."

    In other words, and this has nothing whatsoever to do with corporate
    software, unless you're in that 5 percent (probably less) of current
    programmers who can write high-quality C++, you're much better off
    sticking with VB.NET or C#, Java, Python, and Ruby (all of these are
    managed code in the spirit of the term).

    Point being, these "managed" languages have made the mass market
    possible. The "whole managed-code/auto-garbage-collected concept" is the
    only reason over 90 percent of these "mass market" apps can even exist.

    Overall, maybe you really should have read the entire article. I'd also
    bet you've never used WPF, so you have no idea what *it* brings to the
    table compared to MFC or WinForms. Or for that matter Qt or GTK++.

    AHS
     
    Arved Sandstrom, Jun 6, 2011
    #2
    1. Advertising

  3. In message <yg1Hp.353$>, Arved Sandstrom wrote:

    > Right at the end the author says:
    >
    > "The development team lacks the resources to build equivalent
    > functionality in native code.
    >
    > "The last point is important. Maybe a hotshot team of C/C++ developers
    > could make a better job, but if you don’t have such a team or the money
    > to hire it, it is not so relevant."
    >
    > In other words, and this has nothing whatsoever to do with corporate
    > software, unless you're in that 5 percent (probably less) of current
    > programmers who can write high-quality C++, ...


    Maybe that’s the point: such skills are less common among corporate types.

    > Point being, these "managed" languages have made the mass market
    > possible.


    And yet most mass-market apps avoid them.
     
    Lawrence D'Oliveiro, Jun 6, 2011
    #3
  4. On 06/06/2011 02:47 AM, Lawrence D'Oliveiro wrote:
    > The whole managed-code/auto-garbage-collected concept may really appeal to
    > corporate code-cutter types, but I think it has real trouble in the mass
    > market.


    From a programming language design concept, one thing is abundantly
    clear: manually-managed memory is a failure. Most programmers--even the
    very best--have very little ability to prevent memory from being leaked.
    That's why pretty much everyone accuses every very large application
    written in native languages as acting like a leaky bucket: Windows,
    Firefox, etc.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 6, 2011
    #4
  5. On 6 Giu, 17:35, Joshua Cranmer <> wrote:
    > On 06/06/2011 02:47 AM, Lawrence D'Oliveiro wrote:
    >
    > > The whole managed-code/auto-garbage-collected concept may really appealto
    > > corporate code-cutter types, but I think it has real trouble in the mass
    > > market.

    >
    >  From a programming language design concept, one thing is abundantly
    > clear: manually-managed memory is a failure. Most programmers--even the
    > very best--have very little ability to prevent memory from being leaked.
    > That's why pretty much everyone accuses every very large application
    > written in native languages as acting like a leaky bucket: Windows,
    > Firefox, etc.


    In fact, almost every language in use today[*] - with the notable
    exception of C and C++ - features either garbage collection or some
    simpler form of automatic memory management. PHP, Python, Perl,
    Ruby, ... are not perceived as "bloated" while Java and C# are. So,
    memory management alone can't be the explanation for the (apparent)
    bloat. Perhaps it has more to do with the kind of applications that
    are most commonly written in each language, and the programming
    paradigms, styles and patterns that are most commonly used in each
    language.
    Also, it should be stressed that "managed" and "native" are not
    necessarily in opposition: HotSpot compiles to native code, yet it's
    still managed code, for example.

    [*] I mean languages in which new projects are actively being written;
    maintenance of old COBOL and FORTRAN code does not count.
     
    Alessio Stalla, Jun 6, 2011
    #5
  6. On Mon, 06 Jun 2011 10:47:10 -0700, Alessio Stalla wrote:

    > [*] I mean languages in which new projects are actively being written;
    > maintenance of old COBOL and FORTRAN code does not count.
    >

    Garbage collection and stack management are largely irrelevant for COBOL
    - all data space is declared statically and the ways in which PERFORM can
    be used more or less guarantees that its use will not involve the stack.
    About the only use that COBOL might make of the stack would be to call
    separately compiled modules, i.e. with the CALL verb.

    I've never had much to do with Fortran, but from what I've seen of it
    much the same would be true: no dynamically declared off-stack data and
    the stack only used for subroutine calls, parameter passing and a
    subroutine's local variables.

    IOW neither language needs a garbage collector.


    --
    martin@ | Martin Gregorie
    gregorie. | Essex, UK
    org |
     
    Martin Gregorie, Jun 6, 2011
    #6
  7. On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
    > In message <yg1Hp.353$>, Arved Sandstrom wrote:
    >
    >> Right at the end the author says:
    >>
    >> "The development team lacks the resources to build equivalent
    >> functionality in native code.
    >>
    >> "The last point is important. Maybe a hotshot team of C/C++ developers
    >> could make a better job, but if you don’t have such a team or the money
    >> to hire it, it is not so relevant."
    >>
    >> In other words, and this has nothing whatsoever to do with corporate
    >> software, unless you're in that 5 percent (probably less) of current
    >> programmers who can write high-quality C++, ...

    >
    > Maybe that’s the point: such skills are less common among corporate types.


    That's very likely true, but not for the reasons you'd like to think. In
    your Weltanschauung the reason "corporate" developers aren't good at C++
    is because they just don't have the chops for it - in reality, the
    reason most developers who write enterprise software aren't all that
    good at C++ is because C++ is a bad fit for most applications of that
    sort, so why use it?

    Fact of the matter is, a lot of application domains have preferred
    languages. If you think that the application domain is silly, do you
    also think that the associated languages are silly?

    I'll hazard a guess that you suck pretty hard at a whole bunch of
    programming languages. I'll be charitable and ascribe that fact to you
    just not ever having used them. So do you assume that whatever types of
    applications those languages are best suited for are stupid, just
    because you don't know those languages? Or to return to your way of
    thinking, I guess others would be right in stating that you are
    substandard because you don't know those languages.

    >> Point being, these "managed" languages have made the mass market
    >> possible.

    >
    > And yet most mass-market apps avoid them.


    I don't know about that - the huge majority of all websites are written
    with managed code.

    AHS
     
    Arved Sandstrom, Jun 6, 2011
    #7
  8. In message <isis49$cpq$>, Joshua Cranmer wrote:

    > From a programming language design concept, one thing is abundantly
    > clear: manually-managed memory is a failure.


    And yet managed code has failed to take off in the mass market. Why is that?

    > Most programmers--even the very best--have very little ability to prevent
    > memory from being leaked. That's why pretty much everyone accuses every
    > very large application written in native languages as acting like a leaky
    > bucket: Windows, Firefox, etc.


    And yet it is the “managed†apps that tend to be the memory hogs.
     
    Lawrence D'Oliveiro, Jun 6, 2011
    #8
  9. In message
    <>, Alessio
    Stalla wrote:

    > PHP, Python, Perl, Ruby, ... are not perceived as "bloated" while Java and
    > C# are.


    Maybe it’s because the former do reference-counting (freeing up most things
    the moment they become unreachable) while the latter don’t.
     
    Lawrence D'Oliveiro, Jun 6, 2011
    #9
  10. In message <BXaHp.890$>, Arved Sandstrom wrote:

    > On 11-06-06 08:04 AM, Lawrence D'Oliveiro wrote:
    >
    >> In message <yg1Hp.353$>, Arved Sandstrom wrote:
    >>
    >>> Right at the end the author says:
    >>>
    >>> "The development team lacks the resources to build equivalent
    >>> functionality in native code.
    >>>
    >>> "The last point is important. Maybe a hotshot team of C/C++ developers
    >>> could make a better job, but if you don’t have such a team or the money
    >>> to hire it, it is not so relevant."
    >>>
    >>> In other words, and this has nothing whatsoever to do with corporate
    >>> software, unless you're in that 5 percent (probably less) of current
    >>> programmers who can write high-quality C++, ...

    >>
    >> Maybe that’s the point: such skills are less common among corporate
    >> types.

    >
    > That's very likely true, but not for the reasons you'd like to think.


    So you concede my point.

    > I'll hazard a guess that you suck pretty hard at a whole bunch of
    > programming languages.


    I have published code in a whole bunch of different languages, just in this
    noisegroup alone. And there’s more in my GitHub area, as well as a patch or
    two floating around elsewhere. I will happily listen to criticism from you
    .... the day that you can do the same.
     
    Lawrence D'Oliveiro, Jun 7, 2011
    #10
  11. On 6/6/2011 3:17 PM, Lawrence D'Oliveiro wrote:
    > In message<isis49$cpq$>, Joshua Cranmer wrote:
    >
    >> From a programming language design concept, one thing is abundantly
    >> clear: manually-managed memory is a failure.

    >
    > And yet managed code has failed to take off in the mass market. Why is that?


    Because you can't see the mass market. The use of HTML 5 and
    JavaScript-based applications is taking off. And what is JavaScript? Why
    managed code. To deny that this is the case is to deny the success of
    the iPhone, Android, et al: hell, even Microsoft is pushing for HTML 5-y
    things in Windows 8.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 7, 2011
    #11
  12. Lawrence D'Oliveiro

    BGB Guest

    On 6/6/2011 8:35 AM, Joshua Cranmer wrote:
    > On 06/06/2011 02:47 AM, Lawrence D'Oliveiro wrote:
    >> The whole managed-code/auto-garbage-collected concept may really
    >> appeal to
    >> corporate code-cutter types, but I think it has real trouble in the mass
    >> market.

    >
    > From a programming language design concept, one thing is abundantly
    > clear: manually-managed memory is a failure. Most programmers--even the
    > very best--have very little ability to prevent memory from being leaked.
    > That's why pretty much everyone accuses every very large application
    > written in native languages as acting like a leaky bucket: Windows,
    > Firefox, etc.
    >


    you know... some of us use garbage collectors in C...
     
    BGB, Jun 7, 2011
    #12
  13. In message <isjobk$e3s$>, Joshua Cranmer wrote:

    > On 6/6/2011 3:17 PM, Lawrence D'Oliveiro wrote:
    >
    >> In message<isis49$cpq$>, Joshua Cranmer wrote:
    >>
    >>> From a programming language design concept, one thing is abundantly
    >>> clear: manually-managed memory is a failure.

    >>
    >> And yet managed code has failed to take off in the mass market. Why is
    >> that?

    >
    > Because you can't see the mass market. The use of HTML 5 and
    > JavaScript-based applications is taking off. And what is JavaScript? Why
    > managed code.


    I think JavaScript uses reference-counting, too. Why else would it have a
    “delete†statement
    <http://developer.apple.com/library/mac/#documentation/ScriptingAutomation/Conceptual/JSCodingGuide/OOJavaScript/OOJavaScript.html#//apple_ref/doc/uid/TP40006539-SW1>?
     
    Lawrence D'Oliveiro, Jun 7, 2011
    #13
  14. On 6/6/2011 5:06 PM, Lawrence D'Oliveiro wrote:
    > I think JavaScript uses reference-counting, too. Why else would it have a
    > “delete†statement


    Both SpiderMonkey and V8 are garbage-collected. Don't believe me? Here
    is their garbage collector:
    <http://mxr.mozilla.org/mozilla-central/source/js/src/jsgc.cpp>
    <http://code.google.com/apis/v8/design.html> (I don't actually work with
    V8, so I don't know it's class layout so well).

    If you want more evidence, the ECMAScript committee talks about some JS
    things in the context of garbage collection:
    <http://wiki.ecmascript.org/doku.php?id=strawman:gc_semantics>.

    As for python, Python does have a garbage collector because it is very
    easy to accidentally create cycles in references, the big bane of
    reference-counted systems.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 7, 2011
    #14
  15. In message <isjsa7$2j9$>, Joshua Cranmer wrote:

    > On 6/6/2011 5:06 PM, Lawrence D'Oliveiro wrote:
    >
    >> I think JavaScript uses reference-counting, too. Why else would it have a
    >> “delete†statement

    >
    > As for python, Python does have a garbage collector because it is very
    > easy to accidentally create cycles in references, the big bane of
    > reference-counted systems.


    Yes, but like Perl, the garbage collector only gets invoked in those less-
    common cases where you do indeed have such cycles. The rest of the time
    (which is most of the time), reference-counting works just fine.

    > Both SpiderMonkey and V8 are garbage-collected.


    Probably same here.
     
    Lawrence D'Oliveiro, Jun 7, 2011
    #15
  16. Lawrence D'Oliveiro

    Roedy Green Guest

    On Mon, 06 Jun 2011 18:47:30 +1200, Lawrence D'Oliveiro
    <_zealand> wrote, quoted or indirectly quoted
    someone who said :

    >Came across this item
    ><http://www.itwriting.com/blog/3385-lessons-from-evernotes-flight-from-net.html>
    >about how Evernote for Windows abandoned WPF and Dotnet when moving from


    I remember how DOS->Windows evolved recapitulating the evolution of
    mainframes, but requiring hundreds of times the amount of RAM for the
    same functionality. (we still don't have sequential lookahead double
    buffering we had back in the 16K machine days.)

    I think we are doing another round of this recapitulation with
    cellphones and PDAs.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com
    How long did it take after the car was invented before owners understood
    cars would not work unless you regularly changed the oil and the tires?
    We have gone 33 years and still it is rare to uncover a user who
    understands computers don't work without regular backups.
     
    Roedy Green, Jun 7, 2011
    #16
  17. On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
    > In message<isjsa7$2j9$>, Joshua Cranmer wrote:
    >> Both SpiderMonkey and V8 are garbage-collected.

    >
    > Probably same here.


    That is not the case. I have actually patched the source code to
    SpiderMonkey myself, I have literally sat next to the people who work on
    the engine, SpiderMonkey is garbage-collected. Mark-and-trace, although
    the plan is to move to generational GC. I'm not so sure about V8, but
    the page I linked to explicitly mentions generational garbage
    collection, so I'm sure it's in the same boat.

    If you don't believe that, what would it take to get you to believe the
    truth? A signed note from Brendan Eich himself?

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 7, 2011
    #17
  18. In message <isk4vu$baq$>, Joshua Cranmer wrote:

    > On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
    >
    >> In message<isjsa7$2j9$>, Joshua Cranmer wrote:
    >>
    >>> Both SpiderMonkey and V8 are garbage-collected.

    >>
    >> Probably same here.

    >
    > That is not the case.


    So why have a “delete†statement, then?
     
    Lawrence D'Oliveiro, Jun 7, 2011
    #18
  19. In message <>, Roedy Green wrote:

    > I remember how DOS->Windows evolved recapitulating the evolution of
    > mainframes, but requiring hundreds of times the amount of RAM for the
    > same functionality. (we still don't have sequential lookahead double
    > buffering we had back in the 16K machine days.)


    Maybe because there is no benefit to it on current platforms.

    > I think we are doing another round of this recapitulation with
    > cellphones and PDAs.


    “PDAs� Now there’s a term from the 1990s. :)

    Cellphones don’t need to “recapitulate†anything, because they are mostly
    built on adaptations of kernels that have already been used on PCs
    (certainly true of Android and the Apple products).
     
    Lawrence D'Oliveiro, Jun 7, 2011
    #19
  20. On 6/6/2011 8:41 PM, Lawrence D'Oliveiro wrote:
    > In message<isk4vu$baq$>, Joshua Cranmer wrote:
    >
    >> On 6/6/2011 6:38 PM, Lawrence D'Oliveiro wrote:
    >>
    >>> In message<isjsa7$2j9$>, Joshua Cranmer wrote:
    >>>
    >>>> Both SpiderMonkey and V8 are garbage-collected.
    >>>
    >>> Probably same here.

    >>
    >> That is not the case.

    >
    > So why have a “delete†statement, then?


    JavaScript objects are basically hashmaps. The delete statement is the
    JS equivalent of map.remove.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer, Jun 7, 2011
    #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. Salvador I. Ducros

    STL & reducing code bloat

    Salvador I. Ducros, Jul 28, 2003, in forum: C++
    Replies:
    5
    Views:
    1,599
    Howard Hinnant
    Aug 5, 2003
  2. RainBow
    Replies:
    6
    Views:
    370
  3. Steven T. Hatton

    Exceptions and object code bloat

    Steven T. Hatton, Nov 27, 2006, in forum: C++
    Replies:
    5
    Views:
    368
    =?iso-8859-1?q?Kirit_S=E6lensminde?=
    Nov 28, 2006
  4. Tony
    Replies:
    48
    Views:
    1,169
    Mathias Gaunard
    Dec 12, 2006
  5. BGB / cr88192

    hmm: code bloat?...

    BGB / cr88192, Jan 5, 2010, in forum: C Programming
    Replies:
    16
    Views:
    611
    BGB / cr88192
    Jan 6, 2010
Loading...

Share This Page