Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dalvik patch for Facebook for Android

facebook.com

Post reply on HN
Print view View original

41–50 of 95 posts

Re: Dalvik patch for Facebook for Android

#41

Post by no_more_death »

Uninstalled. I checked, and Facebook took up more memory than any other application I have installed, even more than TSF Shell. (By the way, a MUCH more "feature-rich," useful, and snappy app than facebook!) Facebook isn't doing anything comparable to what TSF Shell does, not for me anyway. I bet this is why my phone recently started taking 30 seconds to make a phonecall (!).

I can't believe an app requires 8M RAM just for method names! That's 3% of my entire usable memory (what's left after Motorola Blur takes its share) -- just for the method names for a single app. Surely I must be misunderstanding what goes into that buffer. It's unimaginable to me that they really need such a vast amount of space. It's unimaginable that they really expect their app to work at all on an old phone without choking it to death.

If I grasp this correctly, printing just the method names would create a book double the size of the King James Version of the Bible. Maybe you are going to argue having so many methods is good programming practice, not bloat. But don't argue that you "support" a system when just the method names total around 3% of usable memory for that system. And there are a lot of devices with considerably less memory than what I've got.

Why don't you release a stripped down, "lite" version of the app that works on an Android 2 phone even if it has more than 5 applications installed? Some phones don't even allow uninstalling facebook. They are simply stuck with the bloat (I mean, good programming practices :-).

Re: Dalvik patch for Facebook for Android

#43

Post by MichaelGG »

zurn wrote: post #38
MichaelGG wrote: post #34

Earlier quoted context omitted.

I'm not sure inlining is that difficult. Java bytecode is a relatively straightforward language is it not? Especially if it doesn't have to be for all cases, which, if you're looking at eliminating small methods, it does not have to be. Assuming Java has something like the Cecil library for MSIL, it should be a fairly straightforward task. Although, as you point out, so is fixing up a number.

In order to elide the out-of-line method the compiler must statically prove that it is impossible call outside the visibility of its optimization scope. I'm not familiar with Java compilers but I'd hazard a guess that to exploit this optimization (if it were possible at all) they would probably have to significantly rework their code.

For a shipped app it shouldn't be too hard to perform it across all packages involved, right?

Re: Dalvik patch for Facebook for Android

#45

Post by AnthonyMouse »

simula67 wrote: post #40
AnthonyMouse wrote: post #37

Earlier quoted context omitted.

One of the advantages of open source is that things like that don't tend to happen. If a change to X breaks Y, the X maintainers don't include a horrible hack to avoid breaking it, they just submit a patch to Y. Then the package manager makes sure nobody installs new X without installing patched Y.

What if Y is closed-source? What if source for Y is not available for some other reason? What if your patch breaks Y's behavior on other platforms?

>What if Y is closed-source? What if source for Y is not available for some other reason? What if your patch breaks Y's behavior on other platforms?

Advantages of open source may not apply to closed source.

Re: Dalvik patch for Facebook for Android

#46

Post by prostoalex »

blinkingled wrote: post #17
cek wrote: post #3

It's interesting to see the parallels between Android and Windows in this regard. Here's a story from my past, copied from a blog post I wrote last year: My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers’ (such a…

Came here to opine on the exact same topic! I was going to dig up some Raymond Chen blog entries but your CreateFont example illustrates it equally well. I guess hacks are inevitable when you are dealing with that kind of scale/complexity.

It's less of a scale issue and more of an ease of update issue. Back in the days someone who bought a copy of Windows would take it home, and if it broke some existing software they used, they were going to blame the OS and return it to the store (they surely are not returning WordPerfect or Adobe product that they bought eons ago).

Having always-connected clients and ability to force-update the code changes the game. I wonder if the backwards compatibility culture is still prevalent in Microsoft Windows division, provided they could always push a fix via Windows Update, or tell Adobe, etc. to fix their stuff.

Re: Dalvik patch for Facebook for Android

#47

Post by ars »

cek wrote: post #3

It's interesting to see the parallels between Android and Windows in this regard. Here's a story from my past, copied from a blog post I wrote last year: My first job at Microsoft was providing developer support for the early Windows SDKs. To do my job well, I spent hours studying the Windows SDK documentation, the Windows source code, and writing sample applications. I then spent hours poring over customers’ (such a…

So? How'd you fix it? Don't stop the story halfway...

Re: Dalvik patch for Facebook for Android

#48

Post by vidoc »

Is this me or Facebook tends to self-celebrate itself in most of its tech blog posts? I remember them posting a similar piece a few years back on their memcached scaling hacks - the article had a very similar tone, it was equally modest (e.g: not), and was actually nothing but software engineering imposture aimed at impressing a non-tech audience.

Re: Dalvik patch for Facebook for Android

#49

Post by bvdbijl »

chuinard wrote: post #25

"choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up)" The ICS move wouldn't have been a bad option. It would've helped a lot of users convert to ICS+ devices, which Google probably would've loved. The APIs from 4+ are much more robust than pre-ICS, and it probably would've saved more headaches while building the new version in addition to…

Yeah except they souls shut out lots of users

Re: Dalvik patch for Facebook for Android

#50

Post by tspiteri »

chuinard wrote: post #25

"choose between cutting significant features from the app or only shipping our new version to the newest Android phones (ICS and up)" The ICS move wouldn't have been a bad option. It would've helped a lot of users convert to ICS+ devices, which Google probably would've loved. The APIs from 4+ are much more robust than pre-ICS, and it probably would've saved more headaches while building the new version in addition to…

The ICS move wouldn't have been a bad option.

Maybe in a couple of years, but not yet. Pre-ICS Android still has more than 50% of Android's share.

http://developer.android.com/about/dashboards/index.html

Post reply on HN