5 ms·

Actually, Dalvik's GC just plain sucks, too. Clojure has a similar problem: works fine on desktop JVMs, but even initialising it takes many seconds on Dalvik.

• soc88 14y ago
  Works without problems in Scala. Maybe Clojure isn't using the available resources efficiently enough?
  • loup-vaillant 14y ago
    Maybe the Scala examples you think of indulge in quite a bit of destructive updates? Functional programming style tends to generate lots and lots of objects which die very young. Garbage collectors must be tuned for that. At least they should be generational. Mayhaps Dalvik's current GC is not?
    • masklinn 14y ago
      Aye, seems Dalvik's GC is a pretty simple mark-and-sweep.
    • soc88 14y ago
      > Functional programming style tends to generate lots and lots of objects which die very young. Well, there is a lot of Scala code out there doing exactly that. HotSpot has no problems with short-lived objects in pretty much all its garbage collectors while Dalvik's GC is just a lot less sophisticated and mature. So I mainly agree with you, but the proposition of Language allows producing lots of short-lived objects + Dalvik sucks ------------ Programs in that language have to be slow doesn't hold in my opinion, as seen in the differences between Scala and Clojure.
      • lucian1900 14y ago
        Clojure still generates a lot more garbage, especially during bootstrap. This can be seen easily with VisualVM on the desktop, comparing hello world in the two languages.
      • loup-vaillant 14y ago
        > Well, there is a lot of Scala code out there doing exactly that. I talked about specific examples that I don't even know of. I don't know Scala enough to know whether non-destructive updates are the default. Are they? What about the core libraries? I agree your proposition in fixed width font does not hold. I was merely asserting this one: Program P produces lots of short-lived objects + Dalvik sucks (or is tuned for long lived-objects) ------------------------------------------------- Program P have to be slow
  • lucian1900 14y ago
    Scala generates a lot less garbage, by construction. A lot of that has to do with its compilation model, which is a lot closer to Java's than Clojure's is. Clojure just assumes the JVM can deal with it, and desktop ones do just fine, hence why no one noticed.
• vetinari 14y ago
  Your laptop has 10x memory bandwidth of top-end Android phones (and 20x of midrange phones). Double the numbers for desktop. In short, mobile devices are different than laptops/desktops. If you threat them same, your application will suck.
  • ajross 14y ago
    Closer to 5x than 10x. Don't do the math based on the clock speed, look at the cycle times (which are mostly the same between DDR3 2000 and LPDDR2 533). A desktop or laptop CPU (unless by "laptop" you mean "netbook" -- laptops based on mainstream CPU cores have the same memory interconnect as desktops) will have two 64 bit DRAM channels, a typical phone will have a single 32 bit channel.
  • pacaro 14y ago
    I use completely different threats for mobile devices, laptops, and desktops. If you don't stop misbehaving and start running my code correctly I'll ((forget to take you out of my pants pocket on laundry day)|(see just how far that hinge will bend)|(take you to the landfill)) None of these work BTW. Edit: Sorry
• briancooley 14y ago
  It's been a while since I looked at the Clojure source, but from what I recall, the initialization problem is almost wholly related to loading all of clojure.core, not garbage collection. If you're hitting slowdowns after initialization, there's a good chance it's reflection, not garbage collection. Type hinting can help if that is the case. Because of the way that Clojure reuses immutable data structures, it doesn't do as much garbage collection as one might think.