Hi Sameer,
The first question is, are you converting your XML to ActionScript
classes? And if so, how? If you are using the Flex XML Decoders, then
the following story may help you.
Many years ago, a customer was complaining about slow performance when
receiving a large XML (actually SOAP) response that they had Flex convert
to Value Objects (aka ActionScript Classes). In my investigation, I
discovered that the Flex application only needed a fraction of the XML
tags in the response. For example, (pardon if if email screws up the
formatting), the customer had a DataGrid with about 20 columns:
Employee Name, Address, City, State, Zip, Region, Hire Date, Exit Date,
Salary, Manager, Department, Phone, Home Phone, Mobile Phone, Social
Security, and a few more.
However, the XML for each employee contained lots of other data, including
salary history, benefits history, and more. So, the XML might look like:
<employee>
<firstName>Alex</firstName>
<lastName>Harui</LastName>
<address1>...</address1>
<address2>...</address2>
<city>...</city>
<state>...</state>
<zip>...</zip>
<hireDate>...</hireDate>
And so on, but also
<salaryHistory>
<salary>
<date>..</date>
<pay>..</pay>
</salary>
<salary>
<date>..</date>
<pay>..</pay>
</salary>
<salary>
<date>..</date>
<pay>..</pay>
</salary>
...
</salaryHistory>
</employee>
Some records had dozens of salary and especially benefits history
transactions. The problem with the default XML/SOAP decoding is that it
is going to visit *EVERY* XML tag. It will walk the entire tree, and
create instances of ActionScript Value Objects for all sub-objects in the
tree. Most of the time that's useful, but in this case, it was creating
1000's of SalaryHistory and BenefitHistory objects that were never used or
weren't used in the initial DataGrid. They might have been used to
drill-down into the Employee in some other part of the UI.
So I showed them how to do Lazy decoding. There is no such feature built
into Flex, you have to create your own. Instead of using an Employee
class that might look like:
Class Employee
{
public var firstName:String;
public var lastName:String;
...
public var salaryHistory:Array;
public var benefitsHistory:Array;
}
And having XMLDecoder or SOAPDecoder run over the entire XML, we changed
the customer code to not use any decoder and use a custom lazy "decoder"
that pretty much does:
var employeeArray:Array = [];
var results:XMLList = xml.employee;
var n:int - results.length();
for (var i:int = 0; i < n; i++)
{
employeeArray.push(new Employee(results[I]));
}
Then Employee is rewritten as:
Class Employee
{
private var xml:XML;
public function Employee(xml:XML)
{
this.xml = xml;
// convert XML to AS properties
firstName = xml.firstName;
lastName = xml.lastName;
...
// Only convert non-object properties like String, Number
// Do not convert object properties like SalaryHistory and
BenefitsHistory
}
public var firstName:String;
public var lastName:String;
...
private var _salaryHistory:Array = null;
public function get salaryHistory():Array
{
// generate SalaryHistory array on demand
if (!_salaryHistory)
{
var history:XMLList = xml.salaryHistory;
var n:int = history.length();
for (var i:int = 0; i < n; i++)
_salaryHistory.push(new SalaryHistory(history[I]));
}
return _salaryHistory;
}
private var _benefitsHistory:Array = null;
public function get benefitsHistory():Array
{
// generate BenefitsyHistory array on demand
if (!_benefitsHistory)
{
var history:XMLList = xml.benefitsHistory;
Var n:int = history.length();
For (var i:int = 0; i < n; i++)
_benefitsHistory.push(new BenefitsHistory(history[I]));
}
return _benefitsHistory;
}
}
No other changes to their code was required since the public property
names did not change in the Employee or SalaryHistory and BenefitHistory
classes.
IIRC, this improved conversion time by a factor of 20 (from over 1 minute
down to 2 or 3 seconds) and reduced memory consumption as well. Only the
values actually needed were converted from XML to AS properties. The
SalaryHistory and BenefitsHistory classes were written similarly to
Employee. They had a constructor parameter that was the XML to convert
and converted only the fields they needed.
It also turns out that Flash lazily parses XML, so when the XML arrived as
a String from the server, Flash only converted the top-level tags into XML
nodes and just remember the strings of tags for SalaryHistory. But the
default decoders, since they walked every tag caused Flash to generate an
internal node for every SalaryHistory tag. With the lazy decoding, Flash
has to create many fewer internal nodes right away, also reducing memory
consumption.
HTH,
-Alex
On 2/15/18, 2:35 AM, "Sameer M D" <samdes24...@gmail.com> wrote:
>Hi,
>
>I wanted to know how to implement lazy parsing of XML in Flex. As of now
>we
>are processing a huge XML file, and the parsing is performed using E4X.
>The
>browser is getting crashed due to out of memory as the XML which is
>getting
>loaded is of huge size.
>
>How to implement lazy parsing in Flex and whether lazy parsing solves the
>problem of out of memory.
>
>Thanks in advance
>
>
>
>
>--
>Sent from:
>https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle
>x-users.2333346.n4.nabble.com%2F&data=02%7C01%7Caharui%40adobe.com%7C3b8f2
>525ed864a8123fe08d5746d4030%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6
>36542934934347468&sdata=FmaALUnNZcNh%2B2aw5jTC3Ps6vqaHKOa4nO0JgKHYQrs%3D&r
>eserved=0
