Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Former Sun Mobile JIT Engineers Take On Mobile JavaScript/HTML Performance

samzenpus posted about a year ago | from the point-counterpoint dept.

Cellphones 106

First time accepted submitter digiti writes "In response to Drew Crawford's article about JavaScript performance, Shai Almog wrote a piece providing a different interpretation for the performance costs (summary: it's the DOM not the script). He then gives several examples of where mobile Java performs really well on memory constrained devices. Where do you stand in the debate?"

cancel ×

106 comments

Sorry! There are no comments related to the filter you selected.

First (-1)

Anonymous Coward | about a year ago | (#44287081)

First!

Re:First (1)

YoungManKlaus (2773165) | about a year ago | (#44293977)

you misspelled frist!

I blame the DOM too (5, Interesting)

Anonymous Coward | about a year ago | (#44287095)

An arbitrary tree of arbitrary objects with arbitrary methods of manipulating them thanks to years of incremental changes that are never properly documented (quick! point to the document showing that a select tag has a value attribute!) and are never deprecated.

Re:I blame the DOM too (3, Informative)

pspahn (1175617) | about a year ago | (#44287399)

quick! point to the document showing that a select tag has a value attribute!

I'm not sure what you're looking for here. Are you saying that having a value attribute on a select element is something that is simply undocumented but valid?

Or, are you saying that this is a deprecated attribute still found in the wild and there is no doc to explain this?

Certainly invalid attributes are going to add some overhead to the DOM, but I don't think that's necessarily the reason a sluggish UI can be blamed on the DOM. I would imagine that a simple DOM with ten elements, each element with ten attributes would still be faster than a DOM with 100 elements, each with one attribute. Of course, this largely depends on what you're going to be doing with the elements and the attributes, but in the case of simple UI updates to the DOM, the elements are going to change more often than all of the attributes. You might update a couple attributes here and there, but the rest of the attributes are probably left as they were since they are likely unrelated to whatever UI update you are performing.

Re:I blame the DOM too (-1)

Anonymous Coward | about a year ago | (#44287603)

As a third party observer, I feel you think you understand what he was saying, and maybe even what you're saying has any merit.

Re:I blame the DOM too (1)

Livius (318358) | about a year ago | (#44289087)

Or maybe just most webpages are ridiculously bloated.

Re:I blame the DOM too (0)

Anonymous Coward | about a year ago | (#44290225)

Or maybe just most webpages are ridiculously bloated.

"bloated" with what? whenever any layman sees performance issues these days the blame always ends up on the system being generically "bloated".

Re:I blame the DOM too (2)

Livius (318358) | about a year ago | (#44290861)

How about video and flashy graphics that add no information? Or very complex layouts that get text exactly the way the designer intended and which look horrible on any screen not the target size?

By bloat I mean clutter, not speed.

Re:I blame the DOM too (3)

phantomfive (622387) | about a year ago | (#44287487)

What does your comment have to do with performance? The DOM has some awkward parts, certainly; and more annoying it has cross-platform incompatibilities.

But what does that have to do with performance? How would documenting the value attribute of the select tag make things run faster?

Re:I blame the DOM too (1)

Xest (935314) | about a year ago | (#44294203)

I think what he's saying is that the DOM is poorly designed and that's partly because of and partly contributes to poor documentation.

The net result is a clusterfuck with many other clusterfucks built on top of it and we all know that clusterfucks stacked on clusterfucks are especially slow. Or something.

No seriously, I think there's some merit in the point, that if it's not well designed and everyone and anyone has just thrown their own bits and pieces in and much of it isn't well documented then it becomes hard to optimise. It may be that we could achieve speedups by removing obsolete parts, but if they're not documented then how do we know if they're definitely obsolete? Even if removing obsolete parts themselves doesn't offer a speedup, it at least results in a cleaner code base that is then easier to optimise.

Fixing documentation in itself will have no impact on performance, but it'll definitely help in putting developers in a better position to do things that will achieve performance gains. It would be quite sensible to start looking at how the DOM can be improved by looking through the documentation to see what is and isn't relevant still, and what is and isn't a candidate for improvement, but that becomes a far harder task if documentation is wrong or out of date.

Re:I blame the DOM too (1)

phantomfive (622387) | about a year ago | (#44297175)

I'm not sure, I'm having trouble thinking of what could be removed to make things more optimized......a parallel example is x86, which has many legacy commands, but you don't need to use them.

Re:I blame the DOM too (1)

Xest (935314) | about a year ago | (#44297325)

You may be right, but without accurate documentation, how do we know :) ?

Re:I blame the DOM too (5, Funny)

maxwell demon (590494) | about a year ago | (#44287489)

(quick! point to the document showing that a select tag has a value attribute!)

Here it is. [slashdot.org]

Re:I blame the DOM too (1)

UnknownSoldier (67820) | about a year ago | (#44288199)

Agreed. The old trade-off between:

< -- fast & rigid - - - slow & features/flexibility -- >

Re:I blame the DOM too (1)

gsnedders (928327) | about a year ago | (#44290049)

quick! point to the document showing that a select tag has a value attribute!

It's in HTML [whatwg.org] .

This very much is one of the major achievements of HTML5: specifying what is interoperable and required to avoid breaking the web, but historically undefined. One couldn't practically launch a web browser without reverse-engineering others.

Re:I blame the DOM too (0)

Anonymous Coward | about a year ago | (#44294075)

quick! point to the document showing that a select tag has a value attribute!

DOM level 1 spec; http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/level-one-html.html#ID-798055546
Scroll down till you see the IDL definition block for the "HTMLSelectElement" object definition.

Garbage Collection is not O(GC)=0 (3, Informative)

Anonymous Coward | about a year ago | (#44287203)

I think Drew's article wasn't that performance had to suffer, it was that garbage collection isn't free. It has to take place, though, so it's not an O(GC)=0 component. If garbage collection takes place in a lot of memory, but not -enough- memory, it takes a very long time, in real time. Depending heavily on the application, it may be very visible at the UI level.

Programmers intent on using all of the resources available, and performing intensive tasks, should think about means other than garbage collection.

Re: Garbage Collection is not O(GC)=0 (0)

Anonymous Coward | about a year ago | (#44287499)

In other words, JS or Java is a disaster on memory constrained or generally slow devices e.g. mobile phones. The reason it is there is thanks to Sun's successful marketing.

Re: Garbage Collection is not O(GC)=0 (2)

binarylarry (1338699) | about a year ago | (#44288035)

Properly written Android apps are pretty snappy and they're written in Java.

Granted they run on a different kind of virtual machine but overall it's still pretty similar to the Java runtime.

Re: Garbage Collection is not O(GC)=0 (0)

Anonymous Coward | about a year ago | (#44288541)

As long as they have enough memory. Even with project butter, a device without enough free memory just sssss ss sucks.

Re: Garbage Collection is not O(GC)=0 (2)

Rockoon (1252108) | about a year ago | (#44288915)

only if by 'properly written' you mean 'doesnt use anywhere near all of the available memory'

Re: Garbage Collection is not O(GC)=0 (1)

datavirtue (1104259) | about a year ago | (#44289405)

We'll see a post soon where Sun's unsuccessful marketing is blamed for their demise. If you hadn't noticed, people use a certain technology because it works to solve their problem. Marketing can help spur this but hardly determines the success of any technology. It is adopted/purchased/used because it works and is needed. Don't point to Microsoft either--they have a monopoly that they leveraged successfully, a trait that is baked into that company by the founder and current CEO.

Re:Garbage Collection is not O(GC)=0 (1)

TheDarkMaster (1292526) | about a year ago | (#44288483)

Completing, he also tries to make as clear as possible the importance of managing your memory usage (using GC or not), and how Javascript goes completely against this idea.

Re:Garbage Collection is not O(GC)=0 (3, Interesting)

Anubis IV (1279820) | about a year ago | (#44288629)

That's not the only issue with his statements about garbage collection.

Drew made an argument that garbage collection on mobile performs poorly due to memory constraints on the platform. Almog countered by pointing out that Drew used a desktop garbage collector rather than a mobile garbage collector, which is important, since mobile garbage collectors are more aggressive at cleaning up stuff like unused paths from JIT, meaning that they make better use of their available memory. Almog was quick to note that being more aggressive also means that the garbage collector performs worse than its desktop counterpart.

Stop and re-read that last sentence, because if I'm understanding this correctly, Almog is basically making the argument that we can avoid the memory concerns Drew brought up -- concerns which were only brought up to explain why there are performance issues -- by using a garbage collector that performs worse.

It's possible, I suppose, that the performance hit from being more aggressive is less severe than the performance hit from running up against the limitations of memory more often, but if that's the case, Almog really should have said so, since right now it sounds like he's completely undermining his own point.

Re:Garbage Collection is not O(GC)=0 (1)

swilly (24960) | about a year ago | (#44290353)

The original claim is that performance is worse by orders of magnitude in a memory constrained environments. It doesn't sound like the mobile optimized GC is orders of magnitude worse than a desktop optimized GC, so in a memory constrained environment the mobile GC would perform better than the desktop GC.

Of course, the author doesn't provide any numbers, so all we have to go by are his expertise and that his arguments are reasonable. Further research will be necessary.

Re:Garbage Collection is not O(GC)=0 (1)

Xest (935314) | about a year ago | (#44294245)

I don't really see what's surprising about all that. The mobile GC does more to prevent itself hitting memory constraints, doing more is always going to cost more than doing less so of course the mobile GC will perform worse than the desktop GC.

But I don't think he's saying it performs worse than the desktop one would when it hits memory constraints of the device and that's really the key.

Optimisation is often about the trade-off between between memory/storage and processing. If memory/storage/bandwidth is tight then you can increase CPU usage to take the strain off the memory/storage/bandwidth limitation - compression being the obvious and common example. If CPU is tight and memory/storage/bandwidth is plenty then use big fat pre-processed lookup tables or whatever rather than calculating dynamically as an obvious example in that case.

There's no free lunch, on mobile the constraint seems to be memory more than anything else so it makes sense to use just a little more CPU to prevent hitting the boundaries of that.

I just don't really see the problem. There doesn't seem to be anything new here.

Re:Garbage Collection is not O(GC)=0 (1)

shutdown -p now (807394) | about a year ago | (#44303297)

The real problem is not with raw amortized performance, in any case. It's about responsiveness, which is basically performance at any particular point in time. If said point in time happens to be during a GC cycle, then your latency will be abysmal. Unfortunately, it's very hard if not impossible to ensure that a GC cycle does not occur at the point where latency is critical, especially in a language like JS which gives absolutely no guarantees about what may trigger a GC (or even a memory allocation).

Re:Garbage Collection is not O(GC)=0 (1)

IamTheRealMike (537420) | about a year ago | (#44289005)

Programmers intent on using all of the resources available, and performing intensive tasks, should think about means other than garbage collection.

This debate is as old as the hills. I'll just point out that it's not so much that GC is terrible, so much as it's indelibly associated with managed languages that either are Java or use very Java-inspired designs (like C#) in which objects and heap allocation is treated as being nearly free.

To prove my point, I cite Unreal Engine, a serious piece of code with very tight performance constraints. It's capable of hitting high, smooth frame rates, and it uses a garbage collected heap for the core game state (lots of objects with lots of pointers between them). (reference) [googleusercontent.com] .

None of these things are free, exactly, but if you understand their costs you can still benefit. I think one of the reasons GC has a bad name is that so much code is written in languages like Java or JavaScript by people who, for instance, don't know the difference between a heap and a stack, or were simply never taught how GC works, so they tend to see allocations as free and use as many of them as they want. Older languages like C++ are used by older, more experienced developers who naturally consider the costs of things as they go, and have a bias towards more complex error-prone code that is tighter.

Re:Garbage Collection is not O(GC)=0 (1)

TheRaven64 (641858) | about a year ago | (#44293849)

The core issue is that GC vs no GC is a false dichotomy. You can't get away without GC, the question is whether you use a general-purpose algorithm, like tracing or reference counting with cycle detection, or a special-purpose design. This is especially true on mobile: if a desktop application leaks memory then it will take a while to fill up swap, but it might not be noticed. Apple provides a very coarse-grained automatic GC for iOS: applications notify the OS that they have no unsaved data and then can be kill -9'd in the background and restarted on demand. They also provide reference counting (with explicit cycle breaking via weak references, no automatic cycle collection) as a tool for developers to build per-application memory management strategies. Android, in contrast, provides a finer-grained automatic GC based on generational tracing.

It confuses me that many of the advocates of avoiding automatic GC seem to follow a train of reasoning something like this:

  • Memory management is a hard problem.
  • Therefore, we can't trust a team of skilled programmers to get a general solution right.
  • Therefore, we will trust every average developer to get it right.

Most of the time, GC can be cleanly integrated with event delivery in interactive applications: you set the GC to only collect if memory is exhausted while handling an event and allow application memory to grow, and you then do a more aggressive collection when there are no pending events. This doesn't work for large multiuser server applications, because they can easily do a few hundred GBs of allocations in between idle periods, but it's surprisingly effective for typical desktop and mobile apps.

Re:Garbage Collection is not O(GC)=0 (0)

Anonymous Coward | about a year ago | (#44294803)

The core issue is that GC vs no GC is a false dichotomy. You can't get away without GC, the question is whether you use a general-purpose algorithm, like tracing or reference counting with cycle detection, or a special-purpose design. This is especially true on mobile: if a desktop application leaks memory then it will take a while to fill up swap, but it might not be noticed. Apple provides a very coarse-grained automatic GC for iOS: applications notify the OS that they have no unsaved data and then can be kill -9'd in the background and restarted on demand. They also provide reference counting (with explicit cycle breaking via weak references, no automatic cycle collection) as a tool for developers to build per-application memory management strategies. Android, in contrast, provides a finer-grained automatic GC based on generational tracing.

It confuses me that many of the advocates of avoiding automatic GC seem to follow a train of reasoning something like this:

  • Memory management is a hard problem.
  • Therefore, we can't trust a team of skilled programmers to get a general solution right.
  • Therefore, we will trust every average developer to get it right.

Most of the time, GC can be cleanly integrated with event delivery in interactive applications: you set the GC to only collect if memory is exhausted while handling an event and allow application memory to grow, and you then do a more aggressive collection when there are no pending events. This doesn't work for large multiuser server applications, because they can easily do a few hundred GBs of allocations in between idle periods, but it's surprisingly effective for typical desktop and mobile apps.

"You can't get away without GC"
since you are wrong from sentence 1, why not try again ;)

Re:Garbage Collection is not O(GC)=0 (1)

TheRaven64 (641858) | about a year ago | (#44295841)

Care to explain why I'm wrong? You have to collect garbage somehow (unless you are using an infinitely long tape instead of RAM).

Re:Garbage Collection is not O(GC)=0 (1)

shutdown -p now (807394) | about a year ago | (#44303345)

I think that a more convincing argument is that memory is just one of many scarce resources, and GC only helps you with memory and not everything else. For the rest of it, we still haven't come up with anything better than deterministic finalization (manual or RAII). And once you're forced to use it for everything else, why wouldn't you also use it for memory, especially if it gives you a better memory profile?

Re:Garbage Collection is not O(GC)=0 (1)

shutdown -p now (807394) | about a year ago | (#44303329)

To prove my point, I cite Unreal Engine, a serious piece of code with very tight performance constraints. It's capable of hitting high, smooth frame rates, and it uses a garbage collected heap for the core game state (lots of objects with lots of pointers between them).

Thing is, no-one is trying to do animations in UnrealScript - it's there to script relatively high-level object interactions. All the rendering code and such is implemented in C++, and at that point it is in full control of memory allocation (i.e. it won't get suddenly interrupted by a GC deciding to walk the object graph in a middle of a drawing routine).

No rebuttal (5, Interesting)

arendjr (673589) | about a year ago | (#44287253)

While this post is a valuable addition to Drew's analysis, I feel it's not really a rebutal at all.

Yes, JavaScript is slow for the reasons Drew mentioned and yes, the DOM is a nightmare to optimize for responsive UIs. They're both right.

While this blog also provides some nice insight into how you can have acceptable performance with a GC on mobile, it's not offering any workable alternative that would work for JavaScript. So Drew's article still comes out pretty strong, IMO.

Re:No rebuttal (4, Interesting)

gl4ss (559668) | about a year ago | (#44287519)

I'm just blabberfastebasted about the summary.

first it goes on about javascript and then about mobile java performing really well on some devices.
j2me - commonly known as mobile java, being something entirely different from javascript.. and j2me did pretty well. you could do wolfenstein clones in 128kbytes(was a common .jar size limit, earlier than that 64kbytes was pretty common) on machines with ~300-400kbytes of ram available for you.. and gc worked just fine, so long as you didn't abuse String or do shit like that - but that's a bit easier to code for in java than in javascript imho(reusing objects etc).

dom though.. of course, it's ridiculous to use for high responsive stuff, while javascript itself can run pretty nicely, lacking real threads certainly doesn't help etc of course.. but it's pretty obvious how you can do things with canvas that would bog the dom renderer.

the article is about how javascript on mobile should be doable ok because j2me worked remarkably well? since j2me did work remarkably well on the lower level(really, it did). what did not work out was their api jsr process for j2me which zombied the whole platform and made almost all extensions useless or half useless - had they not fucked it up like that we would not have needed android.

funny thing about j2me is that most of the mobile stuff I have coded over last 10 years is such that you cannot go to a shop now and buy a device that would run them - except for the j2me code, I could still buy a cheapo nokia and run them.

The article didn't say that (2)

digiti (200497) | about a year ago | (#44287787)

It says that JavaScript is inherently slow because of DOM. It says that this should not be applied as a sweeping generalization to all managed languages e.g. Java. Then it gives examples including mobile Java performance where small heap devices work just fine.

Re:No rebuttal (1)

shutdown -p now (807394) | about a year ago | (#44303389)

you could do wolfenstein clones in 128kbytes(was a common .jar size limit, earlier than that 64kbytes was pretty common) on machines with ~300-400kbytes of ram available for you.. and gc worked just fine, so long as you didn't abuse String or do shit like that

A typical J2ME game from that era preallocated a bunch of arrays, and used those arrays to store all game data, since actual objects were so expensive (both raw-size-wise and GC-cost-wise). So GC basically "worked just fine" if it had nothing much to work with, otherwise it didn't and your game crashed on half the phones out there with OOM. The resulting language subset, while technically still Java, was more akin to C without pointers. Which is to say, it was messed up.

I agree. (1)

tlambert (566799) | about a year ago | (#44287647)

This whole conversation should have been retitled "Why web apps are slow on mobile", and not about JavaScript at all.

The comparison between Objective C and Java is totally ridiculous and beside the point; it's the only thing which ties this article to actual mobile Apps instead of web apps, and fails to address the original articles comments on JavaScript.

In principle, Objective C the language can be used for dynamic binding; in practice, the Objective C runtime, as represented in crt1.o, and in the dyld and later dyle dynamic linkers, it can't be. This was an intentional decision by Apple to prevent a dynamic binding override from changing aspects of the UI, and to prevent malicious code being injected into your program - this is a position Apple strengthened by adding code signing.

Comparison to Java of Objective C as a proxy for comparing iOS applications to Android applications is also ridiculous: there are Android native apps, they are just more difficult to write than the Dalvik Apps. Angry Birds, and most media applications, are not run under the Dalvik VM, but are instead run on the native instruction set.

The whole argument made by the article author is not a rebuttal; it's an attempt to twist the conversation in an attempt to beat on his personal hobby horse.

Re:I agree. (1)

TheRaven64 (641858) | about a year ago | (#44293887)

In principle, Objective C the language can be used for dynamic binding; in practice, the Objective C runtime, as represented in crt1.o, and in the dyld and later dyle dynamic linkers, it can't be. This was an intentional decision by Apple to prevent a dynamic binding override from changing aspects of the UI, and to prevent malicious code being injected into your program - this is a position Apple strengthened by adding code signing.

I have to wonder what you're talking about here. First of all, the Objective-C runtime is not in crt1.o. This contains some symbols that allow dyld to find things in the executable. The Objective-C runtime is in libobjc.dyld. Every message send (method invocation) in Objective-C goes via one of the objc_msgSend() family of functions and these all do late binding. You can define a category on a system class and override methods, or you can use method swizzling via explicit APIs such as class_replaceMethod(). Apple does absolutely nothing to stop this, because the OS X and iOS security model does not depend on the integrity of system shared libraries within a process. It is based on the MAC framework from FreeBSD and enforces limits on interactions of the process with the wider system. A process is free to do whatever it wants within its own address space without violating the security model.

Re:No rebuttal (4, Interesting)

slacka (713188) | about a year ago | (#44289097)

While this post is a valuable addition to Drew's analysis, I feel it's not really a rebutal at all.

Yes, JavaScript is slow for the reasons Drew mentioned and yes, the DOM is a nightmare to optimize for responsive UIs. They're both right.

The key issue here is that these web technologies are being shoehorned into areas they were never designed for. From Document Object Model being used for Applications to the lightweight scripting language, JavaScript, being used for heavy weight programming of course the end result is going to be a poor mobile experience.

If W3C and WHATWG seriously want to compete with Android and iOS Apps, they should consider throwing out the DOM and CSS standards and starting over. JavaScript can be fixed, but DOM/CSS are so technically flawed to the core, the sooner they're depreciated, the sooner the web has a real chance as being a generic platform for applications.

Re:No rebuttal (1)

exomondo (1725132) | about a year ago | (#44290375)

For some reason people read this as a rebuttal of Drew Crawford article, it is not. It is merely a response, I accept almost everything he said but have a slightly different interpretation on some of the points.
http://www.codenameone.com/3/post/2013/07/why-mobile-web-is-slow.html [codenameone.com]

Perceived Performance (4, Insightful)

Hamfist (311248) | about a year ago | (#44287283)

I dislike the separation of 'Perceived' vs 'Actual' performance. If I perceive it to be slow, it's slow. This reminds of of the Firefox devs that spent years saying how if an add-on makes their browser a memory hog and a slowpoke, it's not their problem because their performance is fine.

Devs.. If it's slow, it's slow. Call it perceived, call it actual, call it the Pope for all I care. It's a Slow Pope.

Throughput, latency, and latency hiding (4, Interesting)

tepples (727027) | about a year ago | (#44287373)

Perhaps it's a difference between throughput and latency. Nine moms can make nine babies in nine months, offering nine times the throughput of one mom, but each baby still takes nine months from conception to completion. Users tend to notice latency more than throughput unless an operation already takes long enough to need a progress bar. Some algorithms have a tradeoff between throughput and latency, which need fine tuning to make things feel fast enough.

There are also a few ways to psychologically hide latency even if you can't eliminate it. The "door opening" transition screen in Resident Evil is one example, hiding a load from disc, as are some of the transitions used by online photo albums to slowly open a viewer window while the photo downloads.

Re:Throughput, latency, and latency hiding (4, Funny)

aliquis (678370) | about a year ago | (#44288351)

Or you sit there like:

"Stupid animation just show me the content."

Re:Throughput, latency, and latency hiding (1)

snadrus (930168) | about a year ago | (#44291057)

I've appreciated game loading screens that show me my regularly-adjusted variables (weapon choice, health status), the next story segment in an adventure game, or even a static graphic of something I may encounter. My favorite loading screen is the last level's stats. For "business UIs", I'd go for a "tips & tricks" entry.

Re:Throughput, latency, and latency hiding (1)

phantomfive (622387) | about a year ago | (#44291911)

Good tips. I'll probably use something like that in the future.

That's what the article says (1)

digiti (200497) | about a year ago | (#44287409)

The separation is useful to understand where the optimization is necessary. JavaScript could be made less painful if it didn't have DOM manipulation to contend with obviously that's not very practical.

Re:Perceived Performance (0)

Anonymous Coward | about a year ago | (#44288401)

If it's slow, but not perceived to be slow, then what justifies a more difficult development path such as manual memory allocation vs garbage collection?

Re:Perceived Performance (0)

Anonymous Coward | about a year ago | (#44290193)

I dislike the separation of 'Perceived' vs 'Actual' performance. If I perceive it to be slow, it's slow.

Both perceived and actual slowness are slow. It's about being more specific, not about ignoring real problems. As someone else mentioned the solutions to these two types of slowness are very different.

Data vs Hand-waving (5, Insightful)

2megs (8751) | about a year ago | (#44287299)

Crawford brought in lots of data on real-world performance. (e.g. http://sealedabstract.com/wp-content/uploads/2013/05/Screen-Shot-2013-05-14-at-10.15.29-PM.png [sealedabstract.com] )

Almog's rebuttal has a lot of claims with no actual evidence. Nothing is measured; everything he says is based on how he thinks things should in theory work. But the "sufficiently smart GC" is as big a joke as the "sufficiently smart compiler", and he even says "while some of these allocation patterns were discussed by teams when I was at Sun I don't know if these were actually implemented".

Also:

(in fact game programmers NEVER allocate during game level execution)....This isn't really hard, you just make sure that while you are performing an animation or within a game level you don't make any allocations.

I'm a professional game programmer, and I'm laughing at this. If you're making Space Invaders, and there's a fixed board and a fixed number of invaders, that statement is true. If you're making a game for this decade, with meaningful AI, an open world that's continuously streamed in and out of memory, and dynamic, emergent, or player-driven events, that's just silly. For Mr. Almog to even say that shows how much he doesn't know about the subject.

Re:Data vs Hand-waving (1)

digiti (200497) | about a year ago | (#44287431)

It's not a rebuttle, in fact he didn't refute any claim other than the GC article. Read the comments where game programming is also discussed.

I didn't post a rebuttal (5, Interesting)

Shai Almog (2984835) | about a year ago | (#44287569)

I actually agree with almost everything Drew wrote with the exception of his GC statements, I worked for an EA contractor in the 90's doing large scale terrain streaming on what today would be a a computer less powerful than an iPhone so while my game programming experience might be outdated its still valid. Saying that I don't know if its actually implemented only referred to the last section. Like I said, I actually worked on the VM code as well as the elements on top of it. As I said in the comments to the article never might have been harsh but I pretty much stand by it. If you use a GC you need to program with that in mind and design the times where GC occurs (level loading). Most of your dynamic memory would be textures anyway which are outside the domain of the GC altogether and shouldn't trigger GC activity. To avoid overhead in a very large or infinite world you swap objects in place by using a pool, no its not ideal and you do need to program "around" the GC in that regard. OTOH when we programmed games in C++ we did exactly the same thing, no one would EVER allocate dynamic memory during gameplay to avoid framerate cost.

Re:I didn't post a rebuttal (2, Interesting)

IamTheRealMike (537420) | about a year ago | (#44289105)

FYI stack allocation (the optimisation you refer to) is implemented in the JVM for some time already. It is capable of eliminating large numbers of allocations entirely on hot paths [stefankrause.net] . Of course, there is a lot of memory overhead to all of this - the JVM has to do an escape analysis and it has to keep around bookkeeping data to let it unoptimize things.

For some reason they call this optimisation scalar replacement. I'm not sure why. In theory this can help close the gap a lot, because a big part of the reason GC is seen as slow is just because the languages that use it put so much pressure on the heap due to their library and language designs encouraging tons of tiny objects. If you can put them onto the stack then things can get much faster. I use some pretty large and complicated Java apps these days (like IntelliJ) and they seem to perform well, so perhaps things like this have turned the tide somewhat.

Re:I didn't post a rebuttal (1)

Anonymous Coward | about a year ago | (#44289501)

Memory pools and stack allocation are not the same thing. Memory pools contain many same-sized buffers of memory. Stack-allocation puts data on the stack. Usually those are mutually exclusive.

But is it in any mobile VM? (1)

Shai Almog (2984835) | about a year ago | (#44293223)

Thanks. The thing I was unsure about here is whether this is practical in a mobile VM with the added constraint of very limited CPU cache which is the really interesting bit here.

Re:But is it in any mobile VM? (1)

IamTheRealMike (537420) | about a year ago | (#44303145)

I don't believe Dalvik does any kind of escape analysis. It might be something they could put into dexopt and do ahead of time (at install time not runtime).

Re:I didn't post a rebuttal (0)

Anonymous Coward | about a year ago | (#44289467)

You must isolate GC to those times when you can get away with suffering unpredictable GC overhead (level loading.) You must implement pools to work around the GC when you can't suffer unpredictable GC overhead.

Is this probably better than just using something simple and predictable, like ARC? You still can't allocate from the heap in performance critical sections (fragmentation will get you eventually,) so you're no worse off there, and automatic reference counting is no harder to use when you're loading your level either.

You end up in the same place, but without the GC.

BTW, allocating is fine in performance critical sections when done in the right place; the stack. C/C++ permit placing short lived allocations where they belong, cost nothing to "manage" and create no fragmentation. The fact that many languages that purport to be performant move explicit stack allocation beyond the reach of the programmer is unfortunate; hoping heap allocations can be optimized away then discovering that escape analysis fails to accomplish this is just muddling.

Re:I didn't post a rebuttal (0)

Anonymous Coward | about a year ago | (#44290019)

Yeah, it's true that no console programmer would ever dynamically allocate memory in a level without really good reasons, but that's if you only count malloc and new as dynamic allocations. Most games studios I know do this:

// somewhere in the beginning of main()
g_CustomAllocator.Init(malloc(ALL_AVAILABLE_MEMORY));

// later
void SomeFuncThatPerhapsGetsCalledOftenInGame() {
SomeType* var_name = (SomeType*)g_CustomAllocator(sizeof(SomeType));
// do more work with var_name
}

Honestly, I don't see any reason for the hate between GC and non-GC. GC is nice when you're writing code that isn't memory intensive. Non-GC is nice when you want performance (computation or data access). Can't we just have a language that gives us both and stop shoving one or the other down our throats? As in, the language has a built-in keyword/feature that allows one to dynamically bind function/program/thread/whatever-level to your memory arena (GC or non-GC) of choice?

Re:I didn't post a rebuttal (1)

Xest (935314) | about a year ago | (#44294343)

"Can't we just have a language that gives us both and stop shoving one or the other down our throats? As in, the language has a built-in keyword/feature that allows one to dynamically bind function/program/thread/whatever-level to your memory arena (GC or non-GC) of choice?"

Doesn't .NET's CLR do exactly that with C#/C++ and the ability to jump out to unmanaged code?

Alternatively if you prefer unmanaged by default you can just implement a garbage collector in C++ and use it when you need to, avoid it when you don't.

Re:I didn't post a rebuttal (2)

ras (84108) | about a year ago | (#44292781)

I actually agree with almost everything Drew wrote with the exception of his GC statements

I'm courious. Drew said two things about GC:

  • - It's slower than manual memory allocation in memory constrained environments.
  • - It's faster than manual memory allocation where there 5x or more of actual memory usage.

He didn't say GC always introduces huge latencies, probably because given an incremental GC and enough memory it doesn't. So which of the two assertions are you disagreeing with?

Or to put is another way, going by Drew's data if EA had lots of memory for whatever they were putting in the GC heap and their primary consideration was speed, they would have been far better off using GC.

The biggest weakness in Drew's argument that GC is and will remain dominant cause is IMHO the assumption that a phone will always be memory constrained. We have 2G phones now. 4G can't be far away. You can hardly call 4G "memory constrained". If mobile slowness were just caused by GC, my guess is at 4G most apps will have far more than 5x their memory requirements, so GC should actually help. I'm also guessing mobile will remain slow. The trifecta that ensures this is:

  • - JavaScript is and will always remain a slow language, for the reasons Drew says.
  • - CPU speed on mobile will remain slow, again for the reasons he says, and
  • - The one thing area of improvement we are seeing in mobile, the growing in the number of cores, doesn't help JavaScript can't use because it's single threaded.

Re:I didn't post a rebuttal (1)

shutdown -p now (807394) | about a year ago | (#44303437)

If you use a GC you need to program with that in mind and design the times where GC occurs (level loading).

Are you saying that GC should only run during level loading (IIRC, this was actually done in UT 2003)?

If so, then this would require the language/runtime in question to give programmer explicit control over GC (at least to the extent of temporarily disabling it). Which is certainly doable in theory, but I'm not aware of any JS runtime that exposes such a thing to the JS code that runs on top of it.

Re:Data vs Hand-waving (1)

gl4ss (559668) | about a year ago | (#44287649)

with some j2me phones there was a trick to run the gc often enough by calling system.gc(), if you did it every 20-50 usual sprite objects(which had like 20 bytes of data attached per object) it never became a problem and a problem would have been noticing a jerk in animation, scrolling or whatever. though even then you would mostly try to reuse objects. memory was tight on those early devices, but remarkably the garbage collector didn't often become a problem.

I wouldn't trust sun guys to know shit about game programming though, their idea of a j2me game api was pretty shitty, so shitty that you were better off doing your own implementation of the classes(you could do it with earlier j2me classes just as well, is my point). basically they introduced a class that encapsulated keyevent bookkeeping and a tilemap. you were better off doing your own keyevent bookkeeping since you could then offer a button configuration option and you were better off using your own tilemap engine because it was just as fast as their platform provided one and the platform provided one became slower exponentially, so even if you were showing a 10x10 area of the tilemap the phone included implementations became 10x slower if the mapsize was quadrupled(the numbers are about in the ballpark, point is they didn't do a good job of rendering only what was shown).

but gc, that only became a problem if you trashed the memory stupidly, in ways that would have bitten your performance in c++ too. taught me a bit about java though.

Re:Data vs Hand-waving (1)

digiti (200497) | about a year ago | (#44287715)

Most j2me devices didn't use code from Sun.

Re:Data vs Hand-waving (1)

UnknownSoldier (67820) | about a year ago | (#44288267)

And as another professional game programmer I disagree: Good Luck tracking down memory fragmentation.

Real game programmers never call malloc / new from inside the main game loop. They should be allocating from memory pools / heaps. What do you mean you don't have a memory budget for ALL objects, effects, and events ??

Re:Data vs Hand-waving (1)

fzammett (255288) | about a year ago | (#44288827)

I too am a game developer... no, not professional as you are, but I've written almost a dozen games on a number of platforms over nearly 20 years, sold most of them and even had two nominated for some awards years ago. I won't put myself on the same level as you, but I do have some relevant experience.

I would agree if you said the "never" statement is hyperbole... but you wouldn't argue the underlying gist of it, would you? Certainly it's true that a game programmer will seek to MINIMIZE object allocations and deallocations as much as possible within the performance-critical sections of code, right? I think that was what he was getting at, even if he didn't say it very well. Yes, I'd agree, what he LITERALLY wrote is false... but I suspect it was just a case of being overzealous with word choice... get him in a quiet room and I bet he says "yeah, I didn't actually meant NEVER there".

Re:Data vs Hand-waving (1)

caywen (942955) | about a year ago | (#44289195)

I'm with you, and I think a lot of what is said boils down to trying to paint scenarios in black and white. The word "allocation" really doesn't mean anything until one specifies how and what is allocated. An allocation can come from a recycling allocator, slab allocator, or just plain old unoptimized malloc(). To say game programmers never alloc during "game level execution" (whatever that means) is just a gross facepalm statement. But it's certainly common for game developers to develop allocators well optimized to their memory usage patterns. I don't think many serious game developers would heavily use vanilla malloc/free in performance critical game loops.

friggen dummies... (0, Troll)

Anonymous Coward | about a year ago | (#44287303)

If they care about performance why not use C?

Re:friggen dummies... (1)

Anonymous Coward | about a year ago | (#44287359)

If they care about performance why not use assembly?

FTFY

Looking at the generated assembly code (2, Informative)

tepples (727027) | about a year ago | (#44287427)

If they care about performance why not use assembly?

Some people do (in a sense) use assembly when they use C. If a particular inner loop is running too slowly, an expert programmer might look at the code that the compiler generates to see what's going wrong. For example, an inefficient translation of C to assembly language might point to needing const or restrict qualifiers to allow the compiler to make certain optimizations.

Re:Looking at the generated assembly code (1)

stewsters (1406737) | about a year ago | (#44287613)

Some people also do (in a sense) use C when they use Dalvik. The NDK [android.com] is really useful for tight loops for things like physics.

Re:friggen dummies... (2)

angel'o'sphere (80593) | about a year ago | (#44287525)

1) You need 100 times more time to program a certain program if you do it in assembly
2) You need X times the time if you want it running on X platforms (can even be the same processor)

A long known fact in programming is: your programmers productivity in terms of lines of code per day is FIXED. REGARDLESS of language.
That simply means a programmer who is able to "correctly" write 25 - 50 lines of Java per day will also only write like 25 - 50 lines assembly per day.

This is the main reason why we migrated from bytecode/machine code to assembly and from there to MACRO ASSEMBLERS and from there to Fortran/Cobol and from there to Lisp/SmallTalk.

Then came the many mixed in solutions like C (a portable assembler) / PL1 / ALgol / Pascla /Java etc.

Higher abstraction levels make it possible that programmers are 100 even up to 1000 times faster than our grandfathers with assembly.

Re:friggen dummies... (5, Insightful)

Anonymous Coward | about a year ago | (#44288293)

You're wrong. But not in the way you think. The ability to write abstractions, and an obsession with design patterns, often results in needless abstraction and a loss of focus.

Libraries like C++ STL and Java Collections only make this worse. Why? Because your application is basically one giant data structure. I forgot whether it was Dennis Ritchie, or Ken Thompson, or whomever, but it was once that said good programming is about implementing the correct data structures. Note that this doesn't mean reusing generic data structures; it means drawing upon the universe of conceptual data structures to craft a narrowly focus data structure and algorithm that fits your problem.

If you start out with generic data structures, then you end up working backwards. You have lots of boilerplate code just to use those generic data structures, which you then aggregate and glue together in the same way you would have done from scratch, but with far less code. Programming is not about splicing hash tables together with trees ad hoc. This is a ridiculously reductive perspective on what is programming and how good programs are written.

This is why, almost without fail, real-world applications developed in high-level languages tend to have ridiculously high source line counts. People get carried away with abstraction, including the language implementors with their plethora of generic data structure libraries.

IME, C is *the* sweet spot, if you had to pick a single language. However, you can do better by mixing and matching different languages, especially where they offer unique characteristics--functions as first-class objects + real closures (i.e. not C++ lambdas), coroutines, exceptional optimizing support (e.g. Fortran for iterative numerical algorithms), and functional language characteristics which make is easier to express some kinds of data structures and algorithms. This is why I stay away from C++; it's too much of a pain to mix C++ with various other languages, where almost every language in existence has strong C support.

If people spent as much time maintaing proficiency in different languages instead of trying to do everything in a single language (and grappling with the inevitably cognitive dissonance when defending their choices on web forums), then the world would be a far more efficienct and less bug-prone place.

Re:friggen dummies... (1)

Rockoon (1252108) | about a year ago | (#44289077)

+Bravo, nailed it.

Re:friggen dummies... (1)

phantomfive (622387) | about a year ago | (#44291921)

And yet C would be so much nicer if it had a generic list library......

Re:friggen dummies... (1)

The_Wilschon (782534) | about a year ago | (#44290793)

If they care about performance, why not design custom ASICs?

FTFY

Re:friggen dummies... (0)

Anonymous Coward | about a year ago | (#44287863)

"They" use Objective-C on iOS.

Opinion Verses Empirical Measurement (0)

Anonymous Coward | about a year ago | (#44287341)

From the first article:

So what I’m going to do in this post is try to bring some actual evidence to bear on the problem, instead of just doing the shouting match thing.

From the second article:

Yes they have a cost, no its not a big deal.

The first article has original research with measurements. The second article has "its not a big deal". The first article links to research papers. The second article has "its not a big deal".

With an open mind, I know which one I'm more inclined to believe.

You don't need a study when you have the devices (1)

digiti (200497) | about a year ago | (#44287825)

The article mostly agrees with what Drew said with very few exceptions. The article points at Asha devices (and other devices) that have very small amounts of memory (2mb) and yet perform really well with a GC (and a slow CPU).
The GC study pointed in the Drew article was a desktop study taken out of context.

Re:You don't need a study when you have the device (0)

Anonymous Coward | about a year ago | (#44288491)

The reason why older small embedded devices seemed to work better with Java is because they were using first-generation garbage collectors. Modern compacting collectors use additional space to optimize the speed of collection. But in the grand scheme of things this is a classic time-space tradeoff. The older embedded devices were actually slower running Java overall, but there was no cliff when working set hit a limit of 1/3 or 1/2 of memory, so perceived latency was better overall.

Fact of the matter is, there's no free lunch with a tracing collector. Step back and think about what it actually has to do--walk every object in your entire application, over and over and over and over and over, whether it was strictly necessary or not. And it can't know, of course, because you're not telling it. There are innumerable optimizations that can be made, but they're all constant factor, particularly when you consider a seemingly better than constant time improvement only shifted the cost to memory, or heuristic--awesome for some workloads but really bad for others.

Some people might like to drag up Azul's "pauseless" collector, but ask yourself why everybody hasn't adopted their technology? It's because a truly pauseless, concurrent collector requires extremely strong hardware transaction memory, far beyond what even Haswell provides. Azul originally implemented their GC using a customized processor with a customized hardware MMU. That never sold. Their new software "pauseless" collector is actually a virtual machine sitting below the JVM, which virtually implements in software an MMU with strong transactional guarantees. However, while latency is good, their implementation runs considerably slower overall. This is why they rarely, if ever, publish raw performance benchmarks, but only use cases showing how awesome their latency is.

Anyhow, there is no free lunch with GC. Period. If you out-source your garbage collection to a tracing collector, you're invariably leaving a ton of performance on the table, period. Many times, perhaps even most of the time, it's an okay deal. But don't pretend it's not costing anything, and there's no use fantasizing about a GC that will magically makes those costs go away. It's algorithmically not possible.

My guarantee (2)

sl4shd0rk (755837) | about a year ago | (#44287443)

I guarantee Javascript will perform much better once we get to 16 cores and 3.6Ghz on the standard mobile device.

Re:My guarantee (4, Funny)

i kan reed (749298) | about a year ago | (#44287463)

For the 3 seconds before your battery runs out.

Re:My guarantee (1)

Anonymous Coward | about a year ago | (#44287751)

...or explodes and kills you.

Re:My guarantee (2)

phantomfive (622387) | about a year ago | (#44289215)

One of the points of the original article (linked to in the summary) is that we aren't going to get to 16 cores and 3.6 Ghz on the standard mobile device any time soon. There aren't many desktops that have that kind of processor.......

Re:My guarantee (1)

Flammon (4726) | about a year ago | (#44289571)

And not until Servo (next gen Firefox rewritten in Rust [mozilla.org] ) is out; around version 100.

JIT JS / DOM (0)

Anonymous Coward | about a year ago | (#44287529)

So they want to JIT Javascript? Traversing trees is standard stuff, why should the DOM be so much slower?

Re: JIT JS / DOM (1)

Miamicanes (730264) | about a year ago | (#44291117)

Because DOM *also* re-composes constantly. I saw a Javascript app once that I sincerely *hope* was a joke. It literally tried to emulate a bitmap (pre-Canvas) by fetching a 1x1 cgi-generated PNG image for each unique RGB color used & assembling them mosaic-style into what must have been a 200 megabyte DOM just to draw a 640x480 bitmap pixel by pixel using absolute positioning. It actually *crashed* Firefox, and choked IE 8 for almost 20 seconds (especially the first row, and the last hundred or so rows).

Yeah, mosaics of 32x48 tiles were cute 10 years ago, but Jesus H Christ... SINGLE-PIXEL PNG images generated on the fly & fetched for each unique RGB value? Total *madness*. I wish I could find the site again, just because it was a case study in "how to utterly abuse HTML and browser-based apps."

Re: JIT JS / DOM (0)

Anonymous Coward | about a year ago | (#44291707)

Wow, that is bad. Should have just used background colors.

Slashdot mobile (1)

mu22le (766735) | about a year ago | (#44287579)

I find it very amusing that we are having this conversation on a website that just deployed the slowest suckiest mobile website I have ever seen.

Re:Slashdot mobile (1)

chill (34294) | about a year ago | (#44287639)

Do you get an infinite comment loop?

On Android, if I click on a link in an e-mail to a response to a comment of mine it takes me to the Slashdot mobile site with the parent of my comment.

Scrolling down I get to my comment, then the reply, then my comment again, then the reply again, ad infinitum (or ad crash really).

Re:Slashdot mobile (1)

mu22le (766735) | about a year ago | (#44288011)

Do you get an infinite comment loop?

On Android, if I click on a link in an e-mail to a response to a comment of mine it takes me to the Slashdot mobile site with the parent of my comment.

Scrolling down I get to my comment, then the reply, then my comment again, then the reply again, ad infinitum (or ad crash really).

I do not event get to the comments. The frontpage takes forever to load and cannot be scrolled.

Re:Slashdot mobile (0)

Anonymous Coward | about a year ago | (#44288227)

http://slashdot.org/palm/29/13/07/15/1533256_1.shtml works for me

Re:Slashdot mobile (1)

mu22le (766735) | about a year ago | (#44289021)

That's what I use, but you have to admit using an interface dating back to the 90s it's ridiculous.

Here is a good question (0)

TheSkepticalOptimist (898384) | about a year ago | (#44288111)

Do we want them too?

Java client's are not notoriously strong in the performance department, period. I mean this is why my Blu-ray player sucks as a Netflix client because its Java based. Also no popular "smartphone" created in the last 6 years uses Java as a front end so the reason while mobile devices improved in performance is because those companies avoided using Java in the first place.

Sure, maybe some throwback clamshell feature phone might run Java and perform well, but you are hardly playing Angry Birds or doing anything more then trivial on a clamshell feature phone. There is a reason why everyone abandoned Java based phones the moment iPhone came out.

Also I'd rather have nobody from Sun/Oracle touch Javascript for fear they will lock it down and then sue everyone else because they changed something and suddenly decide they own Javascript.

Two memory models as an solution? (0)

Anonymous Coward | about a year ago | (#44289057)

Would it ease the pain to have the normal, short living objects collected by a reference counter, but introduce a collected keyword for long living/cycled objects to be collected by a tracing collector?

Also: How does memory in Rust work? Is it like that? Can someone explain?

Re:Two memory models as an solution? (1)

TheRaven64 (641858) | about a year ago | (#44293979)

David F Bacon designed some GCs for realtime applications that used reference counting with deferred cycle detection. The longer you defer cycle detection for, the higher the probability that the object will already have been proven to be non-garbage (by having its reference count incremented again) or garbage (by having its reference count reach 0 and it being collected). The trade for this is that it increases the maximum time for the cycle detector to run. You can adjust the delay based on the latency constraints of your application.

Re:Two memory models as an solution? (0)

Anonymous Coward | about a year ago | (#44294455)

Thanks!

While everyone's complaining about JavaScript... (0)

Anonymous Coward | about a year ago | (#44289241)

I'm making lots of money writing it, and having fun not worrying about memory.

Re:While everyone's complaining about JavaScript.. (1)

TheDarkMaster (1292526) | about a year ago | (#44290205)

Until you hit the performance / out of memory wall. When you have to write a serious application, and one day you will, if you do not mind how many resources your application is using will be "hasta la vista" to you.

WAIT ONE SECOND! (1)

Elbart (1233584) | about a year ago | (#44294007)

Apps seem to launch instantly since they have hardcoded splash images

What? iOS-Apps are made to lie regarding their startup-performance? That's golden. 10/10.

Javascript performs excellently (0)

Anonymous Coward | about a year ago | (#44296287)

At delivering malware payloads even in your adbanners. Yes everyone: The brilliant brainiacs that decided scripting documents was "smart to do" just ends up screwing you over in the end. Especially funny since they had the example of macros in documents (like MS Word ones) beforehand and saw how that ended up working out too in malware galore being delivered via those scriptable documents. Why not open up the door and let the trash come blowing in next! Might as well, since the material you consume comes loaded with it because of this idiot's move.

Example cases in point:

Malware More Likely to Come From Legitimate Sites:

http://techtalk.pcpitstop.com/2013/06/26/malware-more-likely-to-come-from-legitimate-sites/?know-notenough= [pcpitstop.com]

and

More dangerous to click on an online advertisement than an adult content site these days, Cisco said:

http://www.securityweek.com/easier-get-infected-malware-good-sites-shady-sites-cisco-says [securityweek.com]

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>