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!

Why JavaScript On Mobile Is Slow

Soulskill posted about a year ago | from the i-blame-the-schools dept.

Programming 407

An anonymous reader writes "Drew Crawford has a good write up of the current state of JavaScript in mobile development, and why the lack of explicit memory handling (and a design philosophy that ignores memory issues) leads to massive garbage collection overhead, which prevents HTML5/JS from being deployed for anything besides light duty mobile web development. Quoting: 'Here’s the point: memory management is hard on mobile. iOS has formed a culture around doing most things manually and trying to make the compiler do some of the easy parts. Android has formed a culture around improving a garbage collector that they try very hard not to use in practice. But either way, everybody spends a lot of time thinking about memory management when they write mobile applications. There’s just no substitute for thinking about memory. Like, a lot. When JavaScript people or Ruby people or Python people hear "garbage collector," they understand it to mean "silver bullet garbage collector." They mean "garbage collector that frees me from thinking about managing memory." But there’s no silver bullet on mobile devices. Everybody thinks about memory on mobile, whether they have a garbage collector or not. The only way to get "silver bullet" memory management is the same way we do it on the desktop–by having 10x more memory than your program really needs.'"

cancel ×

407 comments

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

Easy (5, Interesting)

ArcadeMan (2766669) | about a year ago | (#44244221)

Stop loading dozens of fucking libraries and frameworks and learn to really code.

Re:Easy (2)

Jartan (219704) | about a year ago | (#44244293)

Stop loading dozens of fucking libraries and frameworks and learn to really code.

In other words consider the memory cost of your actions and don't rely on the GC?

That's just not a viable option. (4, Informative)

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

Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.

Even if you don't use jQuery, for example, you're going to need to find and then use some other library that does the same thing, or write a whole shitload of code yourself to implement the same functionality. Zepto works as an alternative for some people, but even it still has some overhead.

That applies to almost anything you want your app to do. If you want to work with objects, arrays or even strings in any way beyond the simplest of manipulations, you're going to need to use some third-party code, or write a whole lot of it yourself.

JavaScript developers are so wholly dependent on these third-party libraries because the JavaScript implementations themselves are so bloody lacking. It's totally different than a language like Python, where there's a rich, yet still compact and efficient, standard library that developers know will be available on just about every user's system. JavaScript programmers have to provide this basic infrastructure with each and every app they write.

Re:That's just not a viable option. (0, Troll)

narcc (412956) | about a year ago | (#44244777)

Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.

That's because you're not familiar with JavaScript. Remember: all those "essential" libraries are written in JavaScript. You'll find that tons of features in those bloated libraries are just useless wrappers!

It's not 2006 any more. If you're still using jQuery, or some other goofy library, you're just wasting everyone's time.

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

Do the web a favor and just learn JavaScript. You'll find that it's more than capable. Your users will undoubtedly appreciate the performance boost!

Re:That's just not a viable option. (-1)

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

LOL @ moron

Re:That's just not a viable option. (4, Insightful)

Nerdfest (867930) | about a year ago | (#44244997)

Learning a flaky, inconsistent language is only prolonging the problem. The web needs to move to something sane. As I said to someone the other day, it's extremely sad that the two most popular languages used for web development are two of the worst languages around (JavaSCript & PHP). It does go a ways towards explaining the quality of web software in general.

Re:That's just not a viable option. (0)

Mashiki (184564) | about a year ago | (#44245111)

Learning a flaky, inconsistent language is only prolonging the problem. The web needs to move to something sane.

What the hell are you talking about? I thought being a programer entitled oneself to be a masochist. After all, if it was about sanity, people would have lit java on fire in 2005, and run the other way.

Re:That's just not a viable option. (4, Insightful)

Nerdfest (867930) | about a year ago | (#44245305)

Compared to those other two, Java is a dream language.

Re:That's just not a viable option. (1)

narcc (412956) | about a year ago | (#44245197)

Learning a flaky, inconsistent language

JavaScript is "flaky" and "inconsistent"?

What on earth are you talking about?

How about giving some examples, son? (1, Interesting)

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

Yeah, we know about document.querySelector(). It's still limited and more of a pain in the ass to use than jQuery's $().

Here's what you're going to do, son. You're going to go through these lists of library functions, and you're going to list the native equivalent, and how well it's supported by the major browsers:

http://api.jquery.com/ [jquery.com]

http://underscorejs.org/ [underscorejs.org]

http://mochi.github.io/mochikit/doc/html/MochiKit/index.html [github.io]

We're even starting easy, and just giving you three JavaScript libraries to cover. Remember, you have to do this analysis for each and every one of those functions.

I sure hope that you don't give up once you realize how wrong you are with your bullshit claim that "every feature has a native equivalent that works across browsers".

Oh, and if you don't prepare this comparison and have it ready within a few hours, we're going to know that you're wrong and that you're full of shit, son.

Re:That's just not a viable option. (4, Insightful)

amicusNYCL (1538833) | about a year ago | (#44245067)

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

That's a pretty naive view that over-simplifies the situation. One major use for a framework, for example, is to normalize the behavior of different browsers. Another major use is to provide implementations to create interface elements. Now, obviously, everything is natively supported because the Javascript framework is right there doing it, natively. But why should I write the necessary logic to create a draggable window, or a tree view, or sortable grid, when I can just pull that in from a framework? ExtJS [sencha.com] is the kind of framework I'm thinking of. Why should I implement ajax-style uploads inside an iframe when they already did that for me, and I can just set up a form panel, indicate it is a file upload form, and write the important stuff?

Even though I can use a massive ExtJS application on a phone, we're not talking about massive applications per se, we're talking about mobile Javascript. So there are things like Sencha Touch [sencha.com] for that. Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?

Or maybe I'm just not "familiar" with Javascript, or development concepts in general. Hopefully you can enlighten me on the merits of reinventing the wheel every time you create something.

Re:That's just not a viable option. (2)

ducomputergeek (595742) | about a year ago | (#44245079)

I built an online shopping cart once that was originally 42k of javascript. Handled all the tracking of items, tax, and shipping in a variety of ways and even developed a multi-vendor capable version that was still under 55k. It powered an online ordering system for restaurants and coffee shops and it worked amazingly fast. All the server had to do was render pages from the products database in HTML. There weren't any writes to the database until the user clicked "order". It ran amazingly fast. Of course we still cared about those things as "broadband" was a 256k DSL line back then.

Re:That's just not a viable option. (3, Informative)

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

The last major jQuery jump dropped IE8 & older support because there were too many quirks they didn't want to bloat everyone's use of the lib with.

Re:That's just not a viable option. (1)

aztracker1 (702135) | about a year ago | (#44244807)

I don't know that it's the purpose of JS to offer quite so much... I know that, for example NodeJS offers a lot, but outside the core, there's not too much there. Underscore takes care of most of the inconsistent bits for current browsers as far as JS itself goes... which is itself relatively light. Most of what Zepto/jQuery offer are with regards to the BROWSER specific bits.

I know it is semantics, but it really bugs me that JS gets such a bad rep because of the browsers' shortcomings.

Re:That's just not a viable option. (5, Insightful)

ShanghaiBill (739463) | about a year ago | (#44244813)

Even if you don't use jQuery, for example, you're going to need to find and then use some other library that does the same thing

Furthermore, popular libraries like jQuery, Mobile-jQuery, etc. are much more likely to have clean, efficient, memory-lite implementations that some "roll-your-own" code. If you choose your libraries carefully, learn to use them, and avoid "rolling-your-own" unless really necessary, your code will certainly be smaller and cleaner, and usually be faster, smaller, and use less memory.

Re:That's just not a viable option. (3, Interesting)

bucktug (306690) | about a year ago | (#44244991)

I really do appreciate a good framework... My favorite one currently is Vanilla-js http://vanilla-js.com/ [vanilla-js.com]

Check it out. Amazing performance.

Re:That's just not a viable option. (0)

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

The very first mistake is try to make a complete GUI application in a shitty language like Javascript.

The second mistake, when you cannot avoid the first one, is to forget that computing resources are finite and therefore must be used as efficiently as possible. This include using bloated frameworks when you CAN make smaller code to do the same job, and rely on the "silver bullet" GC.

Re:That's just not a viable option. (1, Insightful)

loufoque (1400831) | about a year ago | (#44245061)

Yet C developers have no problem using C, which is much more minimal language, to do much more than what you do with JavaScript, and they rarely depend on shitloads of libraries.

Re:That's just not a viable option. (5, Funny)

mypalmike (454265) | about a year ago | (#44245147)

> Yet C developers... rarely depend on shitloads of libraries.


$ ls -l /usr/lib | wc -l
shitloads

Re:That's just not a viable option. (1)

loufoque (1400831) | about a year ago | (#44245279)

You realize you have thousands of packages installed, right? That's not a couple of Javascript apps.

Re:That's just not a viable option. (1)

Dahamma (304068) | about a year ago | (#44245251)

HAH! In fact, it's pretty much the opposite in practice. C requires shitloads more libraries (from the application developer's point of view) to do the same things that (browser-based) Javascript does, since Javascript/HTML already has shitloads of built-in functionality.

Just try to do "much more than what you do with JavaScript" in C by only linking with libc.

The problem with "libraries" in Javascript is they are really pretty much just script includes, and most Javascript apps just load them all into the global namespace up front. Static libraries in C let you only include the code you use, and dynamic libraries tend to be shared across all processes that use them.

Re:That's just not a viable option. (1)

loufoque (1400831) | about a year ago | (#44245363)

You simply code what you need instead of depending on framework that do everything for you.

Re:That's just not a viable option. (1)

brantondaveperson (1023687) | about a year ago | (#44245113)

Python..... efficient....

First time I've heard those two words together in sentence without "is not" between them.

Re:Easy (5, Insightful)

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

We already know how to "really code". We just got sick of reinventing the wheel every time we start a new project. Now we let the libraries do the tedious crap, and we focus our attention on where it's actually needed.

You're going to use our library-heavy code, and you're going to like it. You already do, in fact. You're lying when you pretend otherwise.

Re:Easy (4, Insightful)

girlintraining (1395911) | about a year ago | (#44244471)

Stop loading dozens of fucking libraries and frameworks and learn to really code.

If memory management was so easy, we wouldn't have devoted so much of our programming guides, style manuals, etc., to it. It's not a simple matter of "I wave my hand and the problem goes away." It has existed since before there were "dozens of fucking libraries and frameworks" and at a time when people did know how to "really code"... it has existed since the very. first. computer. And it hasn't been solved to this day.

The main reason, I suppose, is the same reason why we haven't yet found The One True Concrete that all things can be built out of, or the One True Operating System upon which everything can run, or the One True... you get the damn idea. Men much smarter than you have devoted their entire careers to trying to solve the problem, and it's incredibly pretentious of you to toss off a one liner like it's (puts on sunglasses) just a simple matter of programming.

Re:Easy (2)

Jane Q. Public (1010737) | about a year ago | (#44244761)

"... and it's incredibly pretentious of you to toss off a one liner like it's (puts on sunglasses) just a simple matter of programming"

Agree. But the memory management thing really is an issue, too.

Take Android, for example. Android was designed to allow apps to remain in memory until you manually kill them, or the OS gets around to doing it, if ever. And the OS is notoriously lax at doing so. And yes, it was designed that way on purpose. Google doesn't want people killing apps... it cuts off their data stream and ads. Yes, really. So they built the whole OS that way. According to some people I spoke to who worked on Android.

Fortunately workarounds have been developed by the community, but for stock Android it's still a real issue, and it really is built into the OS.

Which still means I agree with you. You aren't going to just put on your programmer sunglasses and on a daily basis sidestep things that were designed into the OS. Ain't gonna happen.

Re:Easy (2)

EdZ (755139) | about a year ago | (#44245205)

There is a strange obsession among many that the only good RAM is empty RAM. Don;t shunt stuff out of memory until you need to, and it'll still be in memory next time you need it. Unless you want to page everything (rather than saving the important parts on sleep and assuming whatever is left in RAM might not be there again at wake but probably will), then there's no reason to turf anything out of RAM until you need that space for something else.

Re:Easy (4, Funny)

loufoque (1400831) | about a year ago | (#44245051)

Memory management is easy. Just program in C instead of JavaScript, problem solved.

Re:Easy (2)

brantondaveperson (1023687) | about a year ago | (#44245141)

Memory management is easy. Just program in C++ using smart pointers instead of JavaScript, problem solved.

FTFY.

Re:Easy (1)

loufoque (1400831) | about a year ago | (#44245261)

That's for plebs.
Better use real RAII.

Re:Easy (2)

brantondaveperson (1023687) | about a year ago | (#44245321)

Point is of course, you can't just forget about memory. And garbage collection has no place on a mobile device.

Re:Easy (1)

loufoque (1400831) | about a year ago | (#44245385)

shared_ptr is reference counting, which is pretty much garbage collection.
Just manage your memory without relying on this but by designing your application taking into account which objects are responsible for the lifetime of other objects (ownership).

Re:Easy (0)

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

It's sad even how few people claiming to be "C" programmers really understand how much work there is to memory management in a modern system beyond libc's "malloc" and "free". Go write (or even just find and read/understand) a useful, efficient, multithreaded embedded/mobile memory management library. Then take it down a level and go understand Linux kernel memory management [tldp.org] .

And I saw you posted that C programmers don't really need to use libraries, anyway. So I assume you are just calling mmap and brk syscalls directly in your code? Sounds simple enough...

Re:Easy (1)

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

What he meant is the waste of memory that frameworks cause. And if you really knows what you are doing, is better to do your own specialized code than using a generic-framework one.

Re:Easy (2)

betterprimate (2679747) | about a year ago | (#44245199)

This is true, but it's JavaScript we're talking about. Project requirements are rarely scoped and developed from the ground up. Most apps and sites are dependent upon bloated frameworks and libraries that are not tailored for mobile capabilities; said frameworks were developed for the desktop.

Not to mention very few JS developers know how to properly manage memory.

Re:Easy (5, Funny)

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

Stop loading dozens of fucking libraries and frameworks and learn to really code.

Because *REAL* programmers don't use libraries or frameworks. In fact, *REAL* programmers don't even use wussy text editors like vi or emacs; they use butterflies.

Re:Easy (1)

JustOK (667959) | about a year ago | (#44244727)

Only 1 butterfly.

Re:Easy (1)

ADRA (37398) | about a year ago | (#44244491)

Thank you so much Ada, you've enlightened an entire generation of developers how wrong we've been our entire careers. Please please teach us the holy grail of never reusing code. We're all listening.

Re:Easy (1)

girlintraining (1395911) | about a year ago | (#44244623)

Thank you so much Ada, you've enlightened an entire generation of developers how wrong we've been our entire careers. Please please teach us the holy grail of never reusing code. We're all listening.

We'll get to that, but first we need to talk about these things called deadlines, managers, and paychecks. After I'm done with the Q&A about those three things, anyone who still wants to seek the Grail may sign up on the sheet here on the desk... (blows away some dust)... Now, open your text books to page 25...
-- Ada

Re:Easy (1, Insightful)

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

Stop loading dozens of fucking libraries and frameworks and learn to really code.

YEAH, anything beyond C is OVERHEAD!

Re:Easy (1)

lesincompetent (2836253) | about a year ago | (#44244867)

Indeed it is. Try to demonstrate the contrary if you want (forwards, not backwards towards assembly).

Re:Easy (1)

egr (932620) | about a year ago | (#44244883)

How the fuck is this insightful?

Re:Easy (2)

hedwards (940851) | about a year ago | (#44245025)

I know, anything beyond manually flipping switches is overhead. C is a terribly bloated mess.

Re:Easy (1)

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

Fucking true.

first!1 fipo (-1)

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

roflcopters!1

always (5, Insightful)

Spaham (634471) | about a year ago | (#44244249)

You always need to think about memory. Like you need to think about what you're doing.
Too bad for the "write app get rich" idiots.

Re:always (2)

egr (932620) | about a year ago | (#44244281)

You always need to think about memory.

+1, you have to always think about memory, no matter what language and garbage collection or not, memory leaks will still bring your system to a crawl.

Re:always (0)

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

What were you talking about?

Re:always (1)

hedwards (940851) | about a year ago | (#44245053)

Garbage collection isn't perfect. The system doesn't have any way of knowing the difference between a value that's been saved for a purpose and one that's just been forgotten about.

Sure, the system can figure out when memory isn't accessible any more, but that doesn't cover all the memory that's been allocated and not released.

Re:always (1, Informative)

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

You think about it a *lot* less in a garbage collected language. There's a big difference between occasionally realizing one part of your system is using a lot of memory and spending time almost every day asking if something will leak or double free.

But they're correct that generational garbage collection uses more RAM to solve the same problems. Usually even if it's compacting.

Re:always (4, Insightful)

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

I write C code all day everyday and never once worry about whether something will leak or double-free. You quickly learn patterns which make object lifetime management safe and simple. In C++ they generically call it RAII. But the basic patterns are simple and are trivial to follow in C, there's just less syntactic sugar (which often is a good thing because you then tend to economize).

The number of times I've leaked memory in C is probably less than I've leaked memory in a GCd language (yes, you can leak memory in GC). If memory management is anything more than a simple chore, then you're doing it wrong. It does take practice, though.

Don't get me wrong, I also use mark+sweep (e.g. Lua) and reference-counted (e.g. Perl) garbaged collected languages. Good times. You just can't use a GC'd languages for anything that will use a lot of memory in a single process. This is why people complain about Java all the time. The time spent walking the object tree grows faster than linearly. The article is fails to grasp that point, although the Microsoft C# engineer nailed it when he mentioned that object references can grow exponentially. The reason why more memory makes it seem like GC is faster is simply because with more memory you can just let junk sit around longer, and then destroy the entire heap all at once. At least, for web pages, which tend to be ephemeral. That doesn't work well for long-lived server processes though, in Java or C#, which can't avoid constantly cycling through all memory.

If you must use a GCd language for memory intensive stuff, you need to use multiple processes and IPC, not just threads, so you can partition your heap memory. Partitioning that way will improve GC algorithmic performance better than linearly. Unfortunately Java and C# don't make multiprocess architectures as easy to implement as in Unix+C, where you can create nameless socket pairs, pre-fork, and pass file descriptors, etc, over the channels, all without polluting any external namespaces--i.e. no loopback ports or temporary files.
 

Re:always (1)

ADRA (37398) | about a year ago | (#44244575)

Most high level languages these days don't leak unless you leave explicit permanent handles to things laying around. Is that what you're talking about, or not-quite garbage collectors which are really just poor substitute reference counting solutions. I haven't worried about true 'leaks' in code for years. Occasionally (like yearly maybe) which are leaking bad references (generally due to greedy singletons). The most interesting part of memory management I and probably most people deal with is are the trade offs between caching vs. re-fetch/re-creating transient data, which has everything to do with memory management and nothing to do with leaks.

Re:always (1)

egr (932620) | about a year ago | (#44244863)

If the language leaks memory (without any misdeed by the programmer) I consider it to be a bad language. Actually I was exactly talking about dead/bad references, caching and frequent re-allocations.

Re:always (2, Insightful)

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

Garbage collected languages have live-leaks that can have exactly the same memory bloat consequences that other memory leaks do. It's where you keep around a reference to an object sub-graph that you aren't actually using. This gets extra bad if you end up building up a linked list of such leaked objects and the linked list grows in size as your application runs. So you do need to think about live leaks every time you store a reference, it's just that the consequences are likely to be less dire if you get it wrong. If you are only thinking about this once a year, that probably means your code is riddled with this issue. So the GP is exactly right in stating that "memory leaks will still bring your system to a crawl" even for garbage collected languages.

Re:always (1)

AuMatar (183847) | about a year ago | (#44244319)

Yup. When I worked at Amazon the #1 question on internal mailing lists was "my Java webservice feezes up and breaks SLA whenever GC kicks in, how do I fix this?". GC is not a silver bullet, and you're going to end up thinking about memory on anything non-trivial.

Re:always (1)

K. S. Kyosuke (729550) | about a year ago | (#44244407)

If Java is the problem, Zing may be the answer.

Re:always (1)

Kjella (173770) | about a year ago | (#44244505)

You always need to think about memory. Like you need to think about what you're doing. Too bad for the "write app get rich" idiots.

But there's plenty "good code, crap idea" that won't make you rich either, most that have gone viral haven't been massively complicated, complex state of the art games. They've been simple, fun and easy to get into while being rather run-of-the-mill technically. Sure, you can't be hopeless but a lot are sufficiently skilled while the l33t coding skillz won't do any good on their own.

Re:always (0)

girlintraining (1395911) | about a year ago | (#44244535)

You always need to think about memory. Like you need to think about what you're doing.
Too bad for the "write app get rich" idiots.

Those "write app get rich" idiots are likely your future employers. They don't know how to program, and they have markedly little understanding of it; That's your job. Oh, and they want it done fast, cheap, and right. Think you can score all three? No? Okay then -- maybe you need to take a step back and realize that programming for money these days is about building a program using a finite number of tools and resources, on a budget, and under a deadline. And I have yet to work on a project where there was enough of anything I needed to do it fast, cheap, and right.

So either I'm one of those "write app get rich idiots", or I'm one of those in the unemployment line I guess. Three guesses which one I picked -- first two don't count. These are the realities of professional programming; We don't have time for perfect... we'll settle for "it compiles" and using something that after hours of beating it with a hammer just started working, but we don't know why... that's just how it is. I didn't write the rules, I just write the code.

First rule of garbage collections (1)

viperidaenz (2515578) | about a year ago | (#44244351)

If you don't release all references to it, it will never be collected (that includes circular references if you're dealing with a reference counting garbage collector, like some IE browsers)

Re:First rule of garbage collections (0)

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

Wrong.
The first rule of garbage collections is "You do not talk about garbage collection."

Re:First rule of garbage collections (0)

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

The Second Rule of garbage collection is "YOU Don't Talk About GARBAGE COLLECTION"

intercept memeory allocation (1)

fermion (181285) | about a year ago | (#44244357)

way back when one of the routines I depended on, and wrote myself, was something that stored all memory allocations, checked before deallocating, and checked on the end of a routine. It basically patched malloc() and dealloc(), or whatever. It would throw an error if I made a mistake. Still, even with such help, that can be easily turning off for production, memory allocation is tough and it one of those things that separates a skilled developer from a script kiddie, so to speak.

But in the real world, in most cases, cycles and memory is much cheaper than skilled developers. Hand coding memory is like hand coding widgets. Like on any project, sometimes optimization is necessary. I would think that mobile apps would be just like any other app. Run a profiler, see what is making the code get stuck, and fix it. When I was doing C, there were times when I had to drop to assembly because the C was too slow. It would been hugely irresponsible to do it all in assembly, but sometimes yes.

Re:intercept memeory allocation (0)

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

I used a development tool over 20 years ago that did something similar. When your program quit it gave you a list of everything you allocated which you failed to free. It would even tell you which lines in your code allocated that memory. It did lots of other amazing things and could catch all sorts of lurking bugs. I've long forgotten its name.

Re:intercept memeory allocation (1)

plover (150551) | about a year ago | (#44244533)

Microsoft has long provided CRT macros for mapping memory allocations and finding leaks. Turning on _CRTDBG_MAP_ALLOC does exactly what you describe. http://msdn.microsoft.com/en-us/library/10t349zs.aspx [microsoft.com]

Re:intercept memeory allocation (1)

GiganticLyingMouth (1691940) | about a year ago | (#44244779)

Sounds like Valgrind [valgrind.org]

Re:intercept memeory allocation (1)

loufoque (1400831) | about a year ago | (#44245169)

Memory management is simple to any C or C++ developer. If you have difficulties with it, you are a bad developer.
In C++, exception-safe memory management can be a bit tricky, but since C++ globally makes things simpler if you follow the right idioms, it still ends up being easier.

I work in high-performance computing, and my focus is on the in-core and shared-memory optimization of numerical code. There is no need to ever go to assembly. Just write the right C code, using attributes or built-ins if necessary (in my field, I use SSE and AVX intrinsics), and check the compiler generates the right thing.

Only a short-term problem (4, Funny)

s7uar7 (746699) | about a year ago | (#44244483)

The only way to get "silver bullet" memory management is the same way we do it on the desktopâ"by having 10x more memory than your program really needs

Give it a couple of years and that's exactly what will happen. Problem 'worked around'.

Re:Only a short-term problem (1)

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

Read the rest of the article (yes, it is really long). It explains why continued large increases in hardware capabilities in mobile may not continue. But Apple will probably keep building devices that take larger and larger pictures, so you'll still run into issues with apps that deal with photos.

GEt off my LAWN! (0)

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

NOW!!!

Explicit memory management. (2, Insightful)

tokizr (1984172) | about a year ago | (#44244539)

You could just 'force' people to use a language with explicit memory management, like by offering [better] support for that particular language (C/C++ is best but I understand people do not enjoy these lower level languages as much). I always thought that the best form of garbage collection is not having garbage collection at all, but managing your memory efficiently and having good allocators. Yet even on languages such as Java/Javascript you can be smart about your objects so to minimize the underlying allocations. I would suppose javascript may be a little harder since it's not strongly typed but it should still be possible.

Re:Explicit memory management. (0)

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

You could just 'force' people to use a language with explicit memory management, like by offering [better] support for that particular language (C/C++ is best but I understand people do not enjoy these lower level languages as much).

I always thought that the best form of garbage collection is not having garbage collection at all, but managing your memory efficiently and having good allocators.

Yet even on languages such as Java/Javascript you can be smart about your objects so to minimize the underlying allocations. I would suppose javascript may be a little harder since it's not strongly typed but it should still be possible.

I love the idea: Write you program so that it manages memory efficiently with a good allocator. And while I'm at it write the program so its meets its requirements and has no bugs.I'll immediately put this suggestion into practice.

Re:Explicit memory management. (1)

loufoque (1400831) | about a year ago | (#44245175)

Don't generate garbage; this way you won't have garbage to collect.

Garbage collection is dumb (2)

0123456 (636235) | about a year ago | (#44244569)

Breaking news. Full story at 11.

Garbage collection is supposed to stop dumb programmers doing dumb things, but in reality it just gives them different ways to do dumb things.

Re:Garbage collection is dumb (1)

Laxori666 (748529) | about a year ago | (#44245091)

Man you try using closures with manual memory management. Quite a nuisance. GC is really quite nice.

Re:Garbage collection is dumb (1)

0123456 (636235) | about a year ago | (#44245115)

GC is really quite nice.

So long as you don't mind spending weeks trying to eliminate the pauses and bloated memory usage and creating internal caching schemes to avoid having to allocate more objects to be garbage collected.

CPython uses reference counting, like objective C (1)

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

The summery mentions Python as one of those garbage collecting languages that have massive garbage collection overhead. But Python actually uses reference counting, which is a garbage collection overhead which is useful in low latency situations. As opposed to the standard mark and sweep garbage collecting like those in Java where every few seconds everything grinds to a hold to clean up memory.

Objective-C tried the mark-and-sweep garbage collection, the first program I made hung for minutes doing garbage collection, I actually had to force the garbage collector to go ahead at smart points in the program to make it behave. Having the same program using reference counting was a completely smooth experience.
This is the reason that mark-and-sweep garbage collection is not allowed on the iPhone.

This problem of mark-and-sweep isn't just an objective-C implementation problem. Java suffers from it identically, this is why it is advocated to force the garbage collector after every request on a website.

Maybe I am living in a fantasy world, but I find it insane that I have to force a garbage collection at correct moments in the program. Which is why I rather like reference counting, or stack allocation.

In Objective-C reference counting is now automated by the compiler, so it is just as programmer-friendly as mark-and-sweep.

Re:CPython uses reference counting, like objective (3, Informative)

EvanED (569694) | about a year ago | (#44244669)

As opposed to the standard mark and sweep garbage collecting like those in Java where every few seconds everything grinds to a hold to clean up memory.

Not to say that tracing collectors don't have a bit of a stuttring problem and I don't want to get into tracing vs reference counting, but:

1) Decent tracing collectors (and the Java VM has had one for a while) are not nearly as bad as you make them out to be, and

2) You mean "tracing collector" rather than mark-and-sweep. The latter is just the simplest form of tracing collectors, which is really pretty bad and is essentially never used. The JVM uses a generational collector, .Net uses a semispace collector (I think), all three of which differ pretty significantly in both mechanics and performance characteristics.

The second point is a bit pedantic and in many stories I probably wouldn't even reply, but in a discussion that is basically specifically about GC it is a good idea to use correct terminology.

Re:CPython uses reference counting, like objective (1)

loufoque (1400831) | about a year ago | (#44245201)

Generational GC can still be mark and sweep (and most of them are). Generational or not is orthogonal.

Re:CPython uses reference counting, like objective (1)

Laxori666 (748529) | about a year ago | (#44245103)

You're talking about "stop-the-world" garbage collection, which Python is also an example of. It doesn't have to do tracing, but it still grinds everything to a halt when it cleans up memory. I think real-time garbage collection is hard to come by these days.

This is what's going to doom FF OS (4, Insightful)

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

This is one of major flaws behind these Web based Mobile OS’s, you think that after WebOS, beautiful as it was, Mozilla would have learned their lesson. Instead, they’re trying to drive underpowered hardware with a HTML/JS. All the web technologies are being shoehorned into areas they were never designed for. From DOM being used for Applications to the lightweight scripting language, JavaScript, being used for Apps, to a bloated HTML render as the platform's UI toolkit.

JavaScript is a nice little scripting language that’s got some nice functional programming features. When you need to need to write heavy applications that require performance, low memory usage, and multithreading, it’s the wrong choice.

Re:This is what's going to doom FF OS (1)

aztracker1 (702135) | about a year ago | (#44244845)

Funny, you don't mention Android being doomed in the same breath... considering even the article mentions that it, being a GC platform has many of the same issues.

Re:This is what's going to doom FF OS (0)

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

Bloated HTML?
What exactly is bloated about HTML?

One of the issues are.. (1)

houbou (1097327) | about a year ago | (#44244679)

the approach to JavaScript development.
Everybody is to trying to use 1 library for all platforms (mobile, desktop) etc.

The first thing is to stop this non-sense.

Use server side technologies to sniff out the client. When working with mobile phones, create or bastardize a library which has the smallest footprint possible to fit your needs.

Re:One of the issues are.. (0)

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

Use server side technologies to sniff out the client.

By which you mean "read the user agent string, which the client has complete control over"?

Re:One of the issues are.. (1)

houbou (1097327) | about a year ago | (#44245211)

well, yes, it is highly possible for the client to fake their user agent string, but in the end, usually, this is done for testing. That being said, if some idiot wants his Firefox to read like IE, well, so be it.

Memory is cheap (0)

msobkow (48369) | about a year ago | (#44244691)

Memory is cheap. Even for mobile devices. But the vendors want to bend you over backwards for every gigabyte.

So put the blame where it belongs: on those who would restrict memory arbitrarily.

64-bit processors are the norm nowadays. Screw anything constrained by 32 bits.

Re:Memory is cheap (1)

aztracker1 (702135) | about a year ago | (#44244855)

going 64-bits gets you very little with a phone that has 512MB of ram.. Personally, given the price of smart phones, they should all have at *LEAST* 2GB of ram.

Re:Memory is cheap (1)

msobkow (48369) | about a year ago | (#44245265)

I say again: Memory is cheap.

Blame the vendor.

Re:Memory is cheap (1)

msobkow (48369) | about a year ago | (#44245281)

Try running Firefox on an old XP box with 512MB of RAM and see how JavaScript chugs.

Re:Memory is cheap (0)

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

So the problem is solved... because you declare it solved?

No wait. The problem is solved... because you know who to blame?

Right. Got it.

Re:Memory is cheap (1)

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

Wrong. Memory on mobile is NOT cheap. Memory in a server is really not cheap (your application is only one in a many applications running, uh oh).

Re:Memory is cheap (1)

msobkow (48369) | about a year ago | (#44245317)

So there is something special about a memory chip built for mobile vs. a memory chip built for desktop?

Server, yes, ECC is fractionally more money. And there is a smaller market for specialized servers that may only have a few tens or hundreds of thousands of customers, so that boosts the price a bit.

But in both the server and mobile spaces, it's primarily an issue of gouging by the vendor. Especially in the mobile space where volume buying is the norm.

Android GC sucks (2)

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

The problem isn't that Android phones have "limited ram", the problem is that Android's garbage collection sucks miserably at dealing with short-lived objects -- a problem that was fixed & mostly a non-issue with J2SE by the time 1.4 or 1.5 came out more than a DECADE ago.

10 years ago, when J2SE 1.5 was out and its garbage-collection problem was already a historical footnote, a laptop with 512mb, 32-gig hard drive, and 700-1000MHz CPU was fairly respectable. A Galaxy S3 has a gig of ram, 16 or 32 gigs of internal flash, and a 32-gig class 10 microSD card costs $20 on sale.

Re:Android GC sucks (1)

cnettel (836611) | about a year ago | (#44245319)

A Pentium III-M or early Pentium M was far faster, on a clock by clock basis, than a single ARM core in most modern smartphones. They get ahead a bit by sporting multiple cores, but that won't help you much in Javascript, or in the really tricky parts of GCing in most VMs (not sure about Dalvik).

A lot depends on what you're trying to do... (3, Insightful)

ducomputergeek (595742) | about a year ago | (#44244959)

Most the "Apps" I'm being hired to write are basically CRUD form apps that are designed to read info from tables in a database. Usually to take forms already in use by desktops written in Java or .Net or in some cases god only knows what and adapt them for use on mobile devices.

I've frankly found jQueryMobile + HTML5 + Phonegap/Cordova makes this task farily easy to undertake client side. Actuallly in most cases the cost is still developing and deploying the API side in your choice of server side scripting language. And often that's based upon a perl script that I wrote circa 2000 to take form input, validate, and then go fetch data from a database and return in XML, YAML, or JSON these days. Other projects, the server side is in PHP or C# or Java. Just depends on what the client already has.

Now I can see trying to buld other types of apps using HTML5/JS is asking for disaster.

Sorry, I'm an old perl guy who thinks use the right tool for the job and there is still more than one way to do it.

Do whats right by the consumer (0)

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

Don't make the consumer pay (in battery life and frustration) for fad frameworks and poor coding practices. A company pays you (who in turn is paid by the consumer) for something Good.

Except, its not? (1)

Shados (741919) | about a year ago | (#44245027)

Short of issues with CSS transforms and in some cases hardware acceleration in general on Android, its not all that slow really.

I have a nexus 4, which isn't low end but its no Galaxy S4 or iPhone 5 either as far as web performance goes, and for the vast majority of websites, it works just fine, with a few delays for ad-heavy sites, sites making heavy use of CSS transforms and animations (which are slow regardless of what you do with JavaScript...I'm being told the situation on iOS is much better), and a few outliers here and there that do things that could be considered edge cases. Sites using jQuery Mobile tend to be terrible, because its a terrible library, but even our main site with tens of thousands of lines of very complex and resource intensive javascript (a fairly advanced web app replicating desktop-like features) works ok, and we didn't even try to optimize it for mobile (we have a mobile specific version but it doesn't have all the features yet so its too early to compare).

But average websites like Slashdot (the normal site, not the crappy mobile one), anything google, news sites, blogs, what have you? The pages load pretty much instantly. How much faster do you really want it to go?

Bollocks (0)

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

I remember running Ruby and Java applications on a 64 meg 133 MHz Pentium machine back in 1997. They worked just fine back then. Many mobile devices today are far more powerful than that. The phone I have in my pocket (a Nexus 4) has thirty two times more memory and a CPU that is clocked eleven times faster, and has four times as many CPU cores! I don't know why VM designers (on mobile at least) don't make good use of the vast amount of research in garbage collection that has been done in the past fifty years and continue to use what amount to the simplest garbage collection algorithms that were first invented by John McCarthy and his colleagues in the 1960s for the first Lisps.

This makes no sense (1)

bill_mcgonigle (4333) | about a year ago | (#44245179)

You could run certainly run Ruby on any mobile device if it had a magic garbage collector that solved everybody's problems. Except there's no such thing that's immune to idiot developers who allocate memory or variables and leave reference to them hanging around. The same problems apply to java on Android.

TFS hasn't inspired me to read TFA, so sorry if it's explained there.

Industry trade secrets revealed (4, Insightful)

WaffleMonster (969671) | about a year ago | (#44245259)

I've found the best way to get developers to stop being lazy is to give them shit hardware.

The mistake is buying the latest quad core 2GB android goodness... Give them a 5 yr old piece of shit and the resulting mobile apps will rock.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?