Profile

Cover photo
Patrick Julien
Lives in
199 followers|70,234 views
AboutPostsReviews

Stream

Patrick Julien

Shared publicly  - 
 
 
I really like this article on the importance of thinking about performance during development, instead of ignoring it completely with the excuse of "premature optimization."

This is especially relevant for mobile development: performance issues that users don't even see can have negative impact on things like battery life; the resource requirements of our code has a direct impact on the hardware it requires to run well, which can completely push the product out of large markets; and user's expectations of the responsiveness of mobile applications tends to be higher than desktop applications even though they are running on slower more constrained hardware and often with much higher-resolution screens.

My own feeling on this is that as a professional software engineer, part of our job is to understand the actual trade-offs we are making during implementation.  There are many things you can do that will be significantly more expensive than other options, which really aren't worth whatever small advantages they provide.  Integral to being proficient at a language, framework, or platform is having a general understanding of the relative efficiency of the various ways you use it so that you can use that knowledge as part of the decision making process throughout development -- from design through implementation and maintenance.  That is not "premature optimization," that is making good use of your tools.

Another way to look at it is this: the hardware you are running on has a fixed amount of resources; when you are implementing your code, you are deciding how to make use of those resources.  Every decision you make that favors other things over efficient use of those resources is also a decision that is limiting the number of features you can deliver to your users, because those resources are no longer available to deliver features.  Of course this doesn't mean you should micro-optimize everything you do, but you also shouldn't ignore efficiency at all -- you need to understand the trade-offs you are making to create the best product for your users.  If you don't, there is a good chance another developer will make better decisions, and be able to developer a superior product that is able to deliver more or better features because they have a more efficient implementation without really sacrificing their productivity.

For example, there are a lot of things in the Java language that can lead to significantly less efficient results than other equally viable approaches.  Selecting between a standard or enhanced for loop can have a 3x difference in performance when iterating over an ArrayList; Java enums are tremendously more expensive in code size than simple static final ints; classes and objects have not-insignificant overhead, so if you take a very class-heavy approach to your implementation you can end up with a significantly larger code size and RAM footprint for your app.

All of these are things that you decide throughout the implementation of your app, but are very hard to fix later on.  This is not the kind of stuff you can throw under a profiler and see, "oh here is the hot spot in these 100 lines of code" and spend a day optimizing that.  Instead what you end up with is pervasive small performance problems throughout your entire app that add up to a large problem, for which a profiler will either not reveal any clear indication of a problem at all (because it is everywhere), or you will end up in an "oh sh*t" moment where you realize that fixing your performance problems are going to require changes all through your code base.

One experience that will always stick with me was when I was working at a previous company on a mobile operating system.  We had spent a few years working on it, had the system up and running on reference hardware, but were not happy with the performance we were getting.  We did a lot of profiling, trying to find what was causing it to be slow, but couldn't find anything significant.  Finally in desperation we went to the hardware manufacturer and asked if they could help out.

The answer we got back from them: "you are running too much code."  Out first reaction was, wtf, of course there is too much stuff being done, but what is it?  But the problem wasn't that there was some specific parts of the platform that needed optimization, it was that just generally all over the place the implementation was too expensive for the hardware it was running on.  It was blowing out the CPU caches all over the place, needing too many instructions given the speed of the CPU, etc.  Fixing such issues requires tremendous work across the code-base reworking how every little thing is implemented to get rid of overhead.  It is lots of steps of find 1% here, .5% there, and on and on, until you either run out of time or you eventually decide "good enough."  It is not a situation you want to be in at the end of your product development.

Our Android documentation has a lot of information on these topics for both Java and the Android framework that every Android developer should have a good understanding of: http://developer.android.com/training/best-performance.html
1
Add a comment...

Patrick Julien

Shared publicly  - 
 
 
A guide to understanding us engineers.

[edit: I forgot to add an important one:
Working as intended = Reality is wrong, and has to be fixed to match the output of the code]
4
3
Thomas Handler's profile photoJody Smith's profile photo
Add a comment...

Patrick Julien

Shared publicly  - 
 
C++ IDEs are definitely due to be disrupted. It will be interesting to see how the refactorings work on a monster code base.

Short preview of the JetBrains C++ IDE including code assistance, wide range of code generation possibilities, refactorings, checks and quick fixes for bette...
1
Add a comment...

Patrick Julien

Shared publicly  - 
 
 
Scalpel - A surgical debugging tool to uncover the layers under your app.

Combine hierarchy viewer, overdraw display, and a splash of gratuitous 3D for an on-device interactive model of your view tree.

https://github.com/JakeWharton/scalpel

I slapped this together in a few hours so it may be a bit rough (especially in the partial 3D conversion). I'd love to get some contributions in. Here's your (and my initial) inspiration: http://revealapp.com/.

#AndroidDev
1
Add a comment...

Patrick Julien

Shared publicly  - 
 
Looks good but why call it "Days of Future Past" if the main characters aren't Kitty Pride and Rachel Summers.
The Great Superhero War of 2014 officially began this week. Mere days after the Marvel Studios assembly line released the trailer for next year’s intriguing...
1
J.R. Freeman (J.R. Freeman Jr.)'s profile photo
 
Because Singer thinks he's Tim Burton, so the source material be damned... 
Add a comment...

Patrick Julien

Shared publicly  - 
 
Breaking Bad just did what most great shows can't... Consistency and quality from beginning to the very end
4
Add a comment...
Have him in circles
199 people
Nesti Joll's profile photo
Richard Kavanagh's profile photo
Philip Rogers's profile photo
Clayton Doty's profile photo
Diane Julien's profile photo
Alex Scrivener's profile photo
Jens Bissinger's profile photo
Fergal Moran's profile photo
skon ye's profile photo

Patrick Julien

Shared publicly  - 
 
Such a great performer. Wish more CEOs were like this.

http://youtu.be/T39RxxyLLBs
1
Add a comment...

Patrick Julien

Shared publicly  - 
 
"But when Facebook bought Oculus a year and a half later for $2 billion in cash and stock, backers wondered: what if I’d asked for equity instead of a poster?"

This is the exact reason why I've never backed any project on Kickstarter.

I can maybe see backing something like the Veronica Mars project for something like say a Serenity sequel but other than that.  This is investing without any possibility of reward other than possibly making the product real.  
The Oculus Rift virtual reality headset raised $2.4 million on Kickstarter, no strings attached. Those donors weren’t looking for a payout; they wanted to support something they believed in, and...
1
Thomas Wrobel's profile photo
 
Not in the least.
Everyone that backs a kickstarter project knows the deal; You are backing because you want it to exist, not because you want to make money. In some case's, its a pre-order.

I hate the FB deal because I think its a poor fit for the platform, and a prefer things to stay independent.
But backers aren't owed anything extra - and they go in knowing that.
Add a comment...

Patrick Julien

Shared publicly  - 
 
This perfectly captures the broken rationale of some of the articles I've been reading.
1
Add a comment...

Patrick Julien

Shared publicly  - 
 
"The kind of people who are successful here like to work and get stuff done". Sounds lovely
What makes Valve so successful? CEO and co-founder Gabe Newell explains.
2
1
Rich Ehmer's profile photo
Add a comment...

Patrick Julien

Shared publicly  - 
 
Still holds up.
This article is written from a real world point of view Silence in the Library was the ninth...
1
Add a comment...

Patrick Julien

Shared publicly  - 
 
This makes me sad
1
Add a comment...
We had to move hotel the very first night. We definitely were not going to sleep there. Everything smells and is dirty. It's not just the room that is dirty but the lobby, the carpet leading up to the room. There is a smell mold that is omnipresent throughout the entire hotel. The door to our room wouldn't close.
Public - 10 months ago
reviewed 10 months ago