jump to navigation

ActionScript and function calls April 11, 2011

Posted by viswaperiyanan in Flex.
6 comments

Recently I was investigating some performance issues that showed up after we migrated our application to flex 4 from 3.6.  After few attempts, narrowed it down to our rather large style sheet with a lot of universal selectors. When I went through Flex source code that performed the selection of appropriate styles to apply for each component  on screen (matchStyleDeclarations in StyleProtoChain), I found nothing wrong.

The screen I was looking at had about 1500 components (several grids). For each of the 1500 UIComponent, the CSSDeclarations were examined for potential matches. Our style sheet had 400 of those . The selection process is straight forward: Examine all 400 CSSDeclerations to find matches. Several other objects – CSSCondition and CSSSelector are involved in finding matches. According to the profiler the system was spending close to 2 seconds to find matching styles. This ended up being a double loop. Outerloop ran 1500 times and inner loop 400 times. The functions calls are several levels deep and across multiple objects.

It turns out that function calls are really costly in Action Script and it becomes very noticeable when function calls are being made in a loop. Here is an example:

var t1:int = getTimer();
for (var i:int =0; i<1500; i++) {
for (var j:int =0; j<1500; j++) {
var k:Number = j+k;
var k1:Number = j+k;
var k2:Number = j+k;
var k3:Number = j+k;
}
}
var t2:int = getTimer();

Takes  35 milliseconds to execute – fair enough. Now let us change the code to do those additions in a function:

private function add(n1:int, n2:int):int{
return n1 + n2;
}

and modify code to use the function:

var t1:int = getTimer();
for (var i:int =0; i<1500; i++) {
for (var j:int =0; j<1500; j++) {
var k:int = add(j,k);
var k1:int = add(j, k);
var k2:int = add(j, k);
var k3:int = add(j,k);
}
}
var t2:int = getTimer();

Takes 1.08 seconds to execute – way  too long!

Solution

Given this finding – went to back to StyleProtoChain and modified the code:

  1. Eliminated all the getter methods by making variables public in CSSSelector, CSSDeclerationd CSSCondition
  2. Inlined all possible functions directly into matchStyleDeclarations (and named the new function fastMatchStyleDeclarations).

The fastMatchStyleDeclarations is large and not so nice to read, but it eliminated most of the performance issues with this loop. We are also working on reducing the number of universal selectors in our CSS file.

Just for curiosity I ran a similar program in Java:

private int add(int i, int j) {
return i+j;
}

and

long l1 = System.currentTimeMillis();
for (int i=0; i<1500; i++) {
for (int j=0; j<1500; j++) {
int k = add(i, j);
int k1 = add(i, j);
int k2 = add (i, j);
int k3 = add(i, j);
}
}
long l2 = System.currentTimeMillis();

Takes 8 milliseconds to execute, the difference is narrowed if we use Objects instead of primitives – but Java continues to be faster by several orders of magnitude

and here is the patch to get around the performance issues when using a large style sheet.

Update – 04/14

James Ward found that he was not getting the same numbers when he ran the test. The numbers above were captured using debug player (on a release build).

Here are the (new) numbers in standard and debug player  (10.2 IE 9):

Release Build Debug Build
Standard Player 20/187 18/190
Debug Player 40/1300 1014/4140

In blue is the time spent executing the loop when running the inline version, the other number in orange is the time spent (in milliseconds) when executing the function variation. So the in-lined version is not 30 times faster, it is just 10 times faster – very surprised to find that running the program on the standard player makes such a big difference.

Memory Leak in Flex 3.2 Lists & Grids February 5, 2009

Posted by Hob in Adobe, Flex, memory leak, Open Source, RIA, User Experience, workday.
11 comments

Ok…so to say that there’s a memory leak in Lists and Grids is a bit redundant as they all inherit from one class, ListBase, which is where the problem is, but a bit of redundancy can be eye-catching.

Anyway…recently I was tracking down an issue filed by one of our testers, and stumbled across a nasty little memory leak in the 3.2 SDK.  Adobe’s already corrected the problem in the 3.3 nightlies, but I thought I’d post my findings here on the chance that anyone else needs the fix in their 3.2 SDK.

The problem is a small class called StageEventProxy.  SystemManager creates an instance of StageEventProxy passing to it your listener whenever one of the following types of events is listened for from SystemManager:

  • MouseEvent.MOUSE_MOVE
  • MouseEvent.MOUSE_UP
  • MouseEvent.MOUSE_DOWN
  • Event.ACTIVATE
  • Event.DEACTIVATE

The problem is that StageEventProxy keeps a hard reference to your listener function.  This means that when garbage collection runs, that listener and the object its attached to will never get marked for garbage collection.

Now, you’re probably thinking, “I’ve never added any of those listeners to SystemManager so I’m free and clear.  Woot!”  Unfortunately you’re not off the hook just yet.  Adobe adds a MOUSE_UP listener to SystemManager in ListBase’s mouseDownHandler():

systemManager.getSandboxRoot().addEventListener(MouseEvent.MOUSE_UP, mouseUpHandler, true, 0, true);

The consequence of this line is that any object that’s an instance of a sub-class of this class (a quick search through the source code revealed List, DataGrid, AdvancedDataGrid, and TileList) will never be garbage collected once the user has clicked on any of the rows in the list. Additionally, because all UIComponents keep a hard reference to their parent component, the garbage collector will also neglect to clean up any of your list’s ancestors in the document hierarchy.

The implications of that for most people are that lists in pop-ups will cause the entirety of your pop-up to never get garbage collected. Here at Workday its a much larger issue, however. Our pages are dynamically created based on XML page definitions we get from the server. These pages are also dynamically unloaded when a new page is received. As a result of the patch for this fix, we’ve seen dramatically reduced memory usage over time in our Flex applications.

Here’s the culprit so you can see what was going on:

////////////////////////////////////////////////////////////////////////////////
//
//  ADOBE SYSTEMS INCORPORATED
//  Copyright 2003-2006 Adobe Systems Incorporated
//  All Rights Reserved.
//
//  NOTICE: Adobe permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
////////////////////////////////////////////////////////////////////////////////

package mx.managers.systemClasses
{

[ExcludeClass]

import flash.display.Stage;
import flash.events.Event;

/**
 * An object that filters stage
 */
public class StageEventProxy
{
	private var listener:Function;

	public function StageEventProxy(listener:Function)
	{
		this.listener = listener;
	}

	public function stageListener(event:Event):void
	{
		if (event.target is Stage)
			listener(event);
	}

}

}

Here’s the updated version Adobe’s including in the 3.3 SDK:

////////////////////////////////////////////////////////////////////////////////
//
//  ADOBE SYSTEMS INCORPORATED
//  Copyright 2003-2006 Adobe Systems Incorporated
//  All Rights Reserved.
//
//  NOTICE: Adobe permits you to use, modify, and distribute this file
//  in accordance with the terms of the license agreement accompanying it.
//
////////////////////////////////////////////////////////////////////////////////

package mx.managers.systemClasses
{

[ExcludeClass]

import flash.display.Stage;
import flash.events.Event;
import flash.utils.Dictionary;

/**
 * An object that filters stage
 */
public class StageEventProxy
{
	private var weakRef: Dictionary = new Dictionary(true);

	public function StageEventProxy(listener:Function)
	{
		this.weakRef[listener] = 1;
	}

	public function stageListener(event:Event):void
	{
		if (event.target is Stage)
		{
			for (var p:* in weakRef)
			{
				var f:Function = p as Function;
				f(event);
			}
		}
	}

}

}

And finally…Here’s a patch file you can drop in your Lib folder that will solve the problem: PATCH FILE

Dave Interview & Podcasts In General September 19, 2008

Posted by Tom Ortega II in Dave, erp, Flex, podcast, workday.
4 comments

In case you somehow missed it, I wanted to point out an interview with our humble leader, Dave Duffield.  He recently participated in the Bill Kutik Radio Show podcast.  One of the highlights in this great podcast is Dave’s rundown of his companies and the technology changes that occurred during each.

Podcasts are a really great technology.  The quality of the recordings can be just as good as what you find on the radio, but with the flexibility of the content to be what you care most about.  I’ll have to admit that I don’t listen to as many podcasts as I should, but that’s just because I get too engrossed in them.  Therefore, that means they’re not an option when coding.  I’d listen to them on my “commute” but since that’s only 10 minutes long, I don’t think I’d get much in that way either.

If you do like podcasts and want to learn a little more about Flex (the technology that powers Workday’s UI), there’s a really great podcast put on by two friends of mine: Jeff Houser and John Wilker.  It’s called The Flex Show and it covers the Adobe Flex technology world.  I’ll have to get Khurram and Frank from the Workday UI team to do an interview with them soon, so you can find out some juicy details about our amazing UI.  In the meantime, you can listen to a brief interview with Charlie Boyle (the UI team’s manager).  You can zoom to minute 14 to get to Charlie in that episode.

FlexSpy enhancements June 3, 2008

Posted by Hob in Adobe, Flex, workday.
Tags:
1 comment so far

Here at Workday the Flex application we’re building is extremely complex (like a fine wine) because our components are built dynamically.  As such, debugging visual and styling issues can often be onerous.  One of my favorite tools for aiding in that task is FlexSpy.  It’s a great tool that lets you view your application’s object hierarchy and inspect the properties on each object in that hierarchy.  Its the closest thing I’ve found in Flex to what Firebug is for Ajax apps.  It even has a “finder” similar to Firebug’s “Inspect” functionality.

There are a couple of problems with FlexSpy, however:

  1. FlexSpy does not have the ability to use SystemManager as its root.  By default it chooses the current Application as its root, thereby rendering you unable to inspect anything else attached to system manager (like pop-ups).
  2. The “finder” mostly works, but doesn’t always let you drill into the child-most component.  For example, if you’re trying to get to a component that’s in a DataGrid cell, the finder will only take you as deep as the grid itself.  From there, you then have to use the tree view to get to the component you’re looking for.

I’ve added a couple enhancements to FlexSpy to try and tackle these problems and posted them in an issue filed on their Google Code page.  The 2 attachments change FlexSpy so it uses SystemManager as its root, and make the finder much more accurate.

I hope that folks will find these changes useful.  If you find any problems with the changes, please feel free to comment here, and I”ll see if I can figure out what’s going on.

Problems moving within a radio group May 12, 2008

Posted by Hob in erp, Flex, RIA, Uncategorized, workday.
add a comment

I’ve recently been trying to add better keyboard control to some of our components.  One such component is basically a container with a set of radio buttons.  The radio buttons not only have labels, but also associated fields (TextInputs, ComboBoxes, etc.) that are only applicable when the radio button next to it is selected.  Thus, the radio button and its associated field both get wrapped in a container for alignment.

This particular component also supports the inclusion of a “None of the above” radio button.  For that particular item in the radio button list we were using a standard Flex RadioButton as there needs to be no associated field next to it.  The result of one of these instances might have a structure similar to this:

<mx:HBox>
 <mx:RadioButton/>
 <mx:ComboBox/>
</mx:HBox>
<mx:HBox>
 <mx:RadioButton/>
 <mx:TextInput/>
</mx:HBox>
<mx:HBox>
 <mx:RadioButton/>
 <mx:CheckBox/>
</mx:HBox>
<mx:RadioButton label="None of the above"/>

The problem I ran into was this: My focus being set on any of the radio buttons in the list, I would start hitting the up arrow.  Once the arrow took me to the radio button physically at the top of the list, it would allow me to move one further, and take me back to the “None of the above” radio button.  For some reason it thought that “None of the above” was first in the list.

I started digging around and here’s what I found:  When RadioButtons are assigned a RadioButtonGroup (via their group property), they register themselves with that RadioButtonGroup via  call to the addInstance() method.  The problem is that the registration does not happen as soon as the group is added.  There are actually several possible places where it can happen, including commitProperties() and updateDisplayList().

This means that the order in which RadioButtons are added to their groups’ array of radio buttons is dependent on the flow of the component lifecycle.  The reason “None of the above” was at the top of the groups movement list was because it was the only one in the list of radio buttons that wasn’t also wrapped in another container.  The extra level of nesting for all the other radio buttons meant that they would get their updateDisplayList and commitProperties methods called after the “None of the above” button’s.

I wound up resolving the problem by wrapping the last radio button in the same type of container as all the rest.  Hopefully this helps someone else avoid having to spend a bunch of time on the same problem.

AutoSizingAdvancedDataGrid that fixes the variableRowHeight issues with mx.controls.AdvancedDataGrid May 9, 2008

Posted by khurram in Adobe, Flex, workday.
Tags: , ,
25 comments

When variableRowHeight is set to true on AdvancedDataGrid,
(a) mx.controls.AdvancedDataGrid ignores attributes such as rowCount.
(b) there is no way to figure out the height of the AdvancedDataGrid instance because we don’t know how much height we will need to show the rows of data in our dataProvider. We can set the height to maxHeight but what of the sum of heights of all rows in our grid is less than the maxHeight, we need our grid to adjust itself to the shorter height but the AdvancedDataGrid does not.

(c) When opening/closing trees in hierarchical data inside the grid, we need the grid to automatically adjust its height. AdvancedDataGrid does not do that when variableRowHeight == true

Both grids side-by-side

The AutoSizingAdvancedDataGrid fixes this issues. It does this by dynamically increasing the height of the array until (a) all the rows in the dataProvider have been displayed or (b) maxHeight has been reached.

Click the image or here to see the example app.  You can right-click and view source as well.

HierarchicalCollectionView: Sort/Filter issues March 26, 2008

Posted by Tom Ortega II in ADG, AdvancedDataGrid, Filtering, Flex, HierarchicalCollectionView, Sorting.
2 comments

We’re working with the AdvancedDataGrid pretty heavily here at Workday. Therefore, we find ourselves using HierarchicalCollectionView by default since ADG wraps HierarchicalData in one.

The problems that we’re encountering is with filtering. I opened up my first Flex Bugbase Jira (woohoo!), so please go vote for it. https://bugs.adobe.com/jira/browse/FLEXDMV-1700

If you set the filterFunction property to null in any other collection, that means you’re done filtering. Since there’s no filterFunction, every item should be shown in the collection and any past filter results should be removed. HierarchicalCollectionView just says, “Well, if there isn’t a filterFunction, then we don’t need to update the data at all.” Bummer. 😦

To see what I mean, check out my test app I submitted with the Jira. It’s located here and has view source enabled so you can make sure I’m not crazy! 🙂

Be sure to vote for sameer’s Sort bug as well: https://bugs.adobe.com/jira/browse/FLEXDMV-1594 It’s pretty much the same thing only for Sorting instead of filtering.

Viewing Workday Through a Prism October 27, 2007

Posted by Tom Ortega II in Desktop, erp, Prism, RIA, workday.
3 comments

Workday’s web application is currently built on top of Adobe’s Flex Framework. Flex let’s us build really cool widgets, which the application developers then turn into useful applications. Flex is great for developing. The current way to access the application is via a web browser, which is great for some reasons (zero-deployment, lightweight client, etc.) and not so great for other reasons (back/forward buttons, tabs in the browser, bookmarking, etc.)

Just because an application is deployed via a web browser doesn’t make it a “website”. Workday is a tool that our customers will use everyday of their work life. They should be able to access it like an other application they use at work by double clicking an icon on the desktop, single clicking an icon in the Quick Launch bar, or choosing an item from the Start menu (Yes, this is a Window’s users view).

Prism offers that functionality. It does it easily without much complication. The nice thing about Prism is that it’s an end-user technology. You don’t have to be a developer to convert your favorite web app into a desktop application. You just need to know a url and you’re done. Yes, it’s currently for Windows only and still pretty slim on features. However, for Workday, we build plenty of features ourselves into the application and it’s nice to see it shine on it’s own. If you’re interested in a bit of the Prism story, read Alex’s entry (he’s working on User Experience at Mozilla).

Below is a screenshot of my desktop. You can see the Workday app running in a tab inside Firefox. This is how I normally access the application. Moving forward though, I’ll be using the “Workday Dev” application instead. It’s the window with the red box outline around it (the red box is my doing to call out the window, Prism doen’t do that). You can also see 2 red circles highlighting the Desktop icon and Quick Launch icon.

If you use Workday and want it to access it like a desktop application, then go to the Mozilla Labs site and give Prism a twirl. Remember, it’s currently Windows only, but Mac and Linux support should be out soon.

Workday Desktop Application via Prism

On Flex Compiler Warnings August 29, 2007

Posted by khurram in 1084, Adobe, Flex, Flex warnings.
5 comments

Some of the Flex compiler warnings are more informational in nature i.e. they are not really warnings just information pointers, sort of like “are you sure this is what you want, if yes then ignore”.  I discuss two of them that directly affect many apps below –

 1.  One such so-called warning comes up when you do not specify an explicit scope for your variable or method.  For example –  

 Declaring a function as follows will give a compiler warning in flex –

public class Foo {

function bar():void {

            //whatever

}

}

The warning would read like this: “1084: function bar will be scoped to the default namespace: Foo.internal and will not be visible outside this package”.  Now this is useful information only if the developer wanted this function to be visible outside its package.  On the other hand, if the intended design was to not have this function visible outside the package, then the signature of the function is correct and specifying any of the scope keywords (public, private or protected) on this function just to get rid of the warning would be incorrect as that’s changing the design.  Package scope is common in modern object oriented languages such as Java and ActionScript 3.  Java compiler does not complain about it, AS compiler shouldn’t too.

2.  The other such warning that comes up very frequently in Flex has to do with bindings.  For example –

 Let’s say that I have a mxml component as follows:

<mx:Text text=”{label}” xmlns….>

            <mx:Script>

                        <![CDATA[

                                    public var label:String;

                        ]]>

            </mx:Script>

</mx:Text>

 Flex will give you a warning that changes to label will not be detected by data binding.  This is an issue only if the developer wants the variable to be bindable.  In many cases in an application where [Bindable] has not been specified for a variable, the developer did not want it to be bindable mostly because the variable will never change its value once it has been initialized or if the intent is that the change in value should not update the bound variable.  One way to achieve this is to manuelly update the value in AS code instead of specifying it as a bound variable in MXML.  That is not the idea case for people like myself who like the elegance of MXML and want to resist the temptation to write AS code.

Flex Memory Leak in mx.core.Container class August 29, 2007

Posted by khurram in Adobe, Flex, memory leak, mx.core.Container.
1 comment so far

We ran into this issue while debugging memory issues in our flex application. This issue has been fixed in the latest beta version of the Flash Player 9.0.60.184. Here is the issue for your reference as it might help you debug memory issues in your application, also download and run the example source to replicate it.

As I was debugging some of the memory issues we are having, I noticed that the objects of types container do not get garbage collected if they have one or more children specified as MXML tags (or alternatively added through component descriptors). I looked at the mx.core.Container class and noticed that it keeps an array called _createdComponents of all the components that were created through their descriptors. It populates that array in the createComponentsFromDescriptors method. The problem is that it never gets rid of the components in the array when they are removed by calling any of the remove methods such as removeAllchildren, removeChildAt etc. That array thus keeps a strong reference to children that had already been deleted and should have been garbage collected. This also gives rise to a circular reference case where the parent and the child both don’t get GC’d.

I have created a small program that might be helpful in reproducing this bug.

  1. After you load the files into a project, run the swf
  2. Click on “Create AS based child”
  3. Click on “Trace Reference”, it will show you the created children
  4. Click on “Remove All” and then “Force GC”
  5. Click on trace reference, you will see no references
  6. Click on “Create Descriptor based child”
  7. Click on “Trace Reference”, it will show you the created children
  8. Click on “Remove All” and then “Force GC”
  9. Click on “Trace Reference”, you will notice that the reference still hangs around even after it has been deleted and GC has run

There is another memory leak that occurs when you specify verticalGap or horizontalGap attributes on any container. This issue has also been resolved in the Flash Player version specified above.

Follow

Get every new post delivered to your Inbox.