Flex Application
Profiling by Example
Jun Heider, Sr. Developer / Technical Trainer
             @RealEyes Media
Who am I?
•   Part of the RealEyes Media team. RealEyes is an
    Adobe partner with a concentration in delivering
    Fla...
What this session is not


•   An extended lecture based on tons of slides.

•   A detailed explanation of memory manageme...
What this session is
•   A quick discussion of things to keep in mind when
    you profile your applications.

•   A whole ...
Why do we profile our apps?



•   Because we want them to run good.

•   Because we don’t want them to be memory hogs.

• ...
Why do we use the Flex Builder Profiler?


•   To find memory leaks.

•   To find excessive allocation.

•   To find long runn...
Flex Builder Profiler doesn’t report everything*
•   Doesn’t report Browser memory.

•   Doesn’t report the following OS me...
System.totalMemory doesn’t report everything either*

 •   Doesn’t report Browser memory.

 •   Doesn’t report the followi...
Operating environment can skew results
•   Think of these factors when profiling:
    •   Different system specs

    •   D...
Just ‘cause you read it don’t mean it’s true



 •   Different environment = Different results

 •   Different code = Diff...
Verify for yourself!


•   Test it with your code base.

•   Test it a number of times to verify that the results
    are ...
Rules of thumb


•   Think about performance from the get-go but
    don’t get carried away.

•   Remember that eventually...
Rules of thumb (cont.)


•   Sometimes the result isn’t worth the effort.

•   Beware of large late-stage optimization eff...
What’s new in Flex Builder 4 Profiler?
•   Improved Object References panel. The shortest
    paths from the object to the ...
Now for the demos (Time permitting)

    •     A couple applications that load various data and
          assests.

    • ...
Where to go from here.
•   Open the AIR application on the USB Flash Drive:
    •   Source code

    •   Links to addition...
Upcoming SlideShare
Loading in...5
×

Jun Heider - Flex Application Profiling By Example

3,028

Published on

This session will be light on slides and heavy on demonstration. The session will start with a brief explanation of the concepts that will be discussed and then kick into high gear with demonstrations and live profiling with the Flex Builder Profiler. During the session the features of the Flex Builder Profiler will be illustrated and light will be shed on how to analyze the data collected by the Profiler. The goal of this session will be to arm the attendee with the ability to use the Flex Builder Profiler to help increase the responsiveness and decrease the memory consumed by their applications.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
3,028
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
61
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Jun Heider - Flex Application Profiling By Example

  1. 1. Flex Application Profiling by Example Jun Heider, Sr. Developer / Technical Trainer @RealEyes Media
  2. 2. Who am I? • Part of the RealEyes Media team. RealEyes is an Adobe partner with a concentration in delivering Flash Platform solutions. • A Flex Developer, just like you. • A Flex Builder debugging and profiling enthusiast. • Experienced in building many Flex and AIR applications for a number of clients: Abeka Academy, Beatport.com, Chase to name a few.
  3. 3. What this session is not • An extended lecture based on tons of slides. • A detailed explanation of memory management and performance theory. • 100, 300, or 400 level
  4. 4. What this session is • A quick discussion of things to keep in mind when you profile your applications. • A whole lot of live Flex Builder Profiler demonstration with actual applications. • A 200 level presentation. • As plain English as possible, let’s get down to what really matters. • Hopefully a lot of fun!
  5. 5. Why do we profile our apps? • Because we want them to run good. • Because we don’t want them to be memory hogs. • Because we don’t want them to crash.
  6. 6. Why do we use the Flex Builder Profiler? • To find memory leaks. • To find excessive allocation. • To find long running processes. • To find excessively called processes.
  7. 7. Flex Builder Profiler doesn’t report everything* • Doesn’t report Browser memory. • Doesn’t report the following OS memory: • Memory used to display visuals. • Memory used to get events. • Memory used to handle Network or File Access. • Doesn’t report the following Player memory: • Memory used to track objects. ( There are memory control blocks used for every object and hidden objects for all display objects. ) • Memory used to store player code and pre-defined variables. • Memory used by the JIT buffer. • Memory used by sub-objects or Strings is tracked on its own row. *Contents of this slide extracted from: http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html (embedded in the presentation SWF)
  8. 8. System.totalMemory doesn’t report everything either* • Doesn’t report Browser memory. • Doesn’t report the following OS memory: • Memory used to display visuals. • Memory used to get events. • Memory used to handle Network or File Access. • Doesn’t report the following Player memory: • Memory used to store player code and pre-defined variables. • Memory used by the JIT buffer. *Contents of this slide extracted from: http://blogs.adobe.com/aharui/2008/09/using_the_flex_builder_3x_prof.html (embedded in the presentation SWF)
  9. 9. Operating environment can skew results • Think of these factors when profiling: • Different system specs • Debug player vs. standard player • AIR on different operating systems • Different browsers • Different versions of the player • Debug build vs. release build • Different versions of the Flex framework
  10. 10. Just ‘cause you read it don’t mean it’s true • Different environment = Different results • Different code = Different results • One round of testing = Likely anomaly
  11. 11. Verify for yourself! • Test it with your code base. • Test it a number of times to verify that the results are consistently worthwhile. • Make sure to verify that your results will carry over into a release build running in the standard player. (No Profiler but you can observe)
  12. 12. Rules of thumb • Think about performance from the get-go but don’t get carried away. • Remember that eventually someone will have to maintain the code. (Readability/Clarity) • Remember that ultimately someone else is usually paying the bill for your optimization efforts.
  13. 13. Rules of thumb (cont.) • Sometimes the result isn’t worth the effort. • Beware of large late-stage optimization efforts. • Establish some baseline performance requirements from stakeholders.
  14. 14. What’s new in Flex Builder 4 Profiler? • Improved Object References panel. The shortest paths from the object to the GC root is much easier to find. • Additional preference configuration options: • Configure which back reference paths to view. • Configure the maximum number of back reference paths to find. • Personal observation: The Profiler seems to work much faster and seems to be more stable.
  15. 15. Now for the demos (Time permitting) • A couple applications that load various data and assests. • An application implemented in several popular frameworks. (Thanks to Tony Hillerson and InsideRIA FrameworkQuest!)* • Flex 4 vs. Flex 3 (Hello World application) • Various algorithm tests. * You can find the FrameworkQuest here: http://www.insideria.com/2008/12/frameworkquest-2008-introducti.html
  16. 16. Where to go from here. • Open the AIR application on the USB Flash Drive: • Source code • Links to additional resources • You can also visit me online or contact me: • (w) http://www.realeyes.com • (b) http://www.iheartair.com • (t) coderjun • (e) jun@realeyes.com • Mad props to both Alex Harui and Tony Hillerson!
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×