--- In flexcoders@yahoogroups.com, "Gordon Smith" <[EMAIL PROTECTED]> wrote: > I'd be interested to know what your use case is that requires a SAX > parser.
In my application, I had two list/search forms which: * query billing-related events (fairly static) * query/rank/prioritise tickets in a ordering/support system In both cases, there can be anywhere between 200 and 50,000 rows returned from a database for each query, sent to the Flex client via SOAP. (That number could grow to 100,000 in three years.) It's *not* useful to have paged views of that many results in the client application; it makes it much more difficult for the user to skim the records and have a good mental picture of what has occurred in the back-end systems. Also, the user wants to type/customise a query, and expects to get back *something* within 1 second, even if the full results take much longer to arrive. > How large is your XML? Did you run into a memory or > performance problem with AS3's E4X capabilities? AS3 on my laptop (Athlon64-2700, WinXP, Firefox 2, non-debug) takes 70 seconds to retrieve the full SOAP response (50000 rows, 8 variable length string columns - about 14MB - over 1-3mbit broadband). I assume about 1 second of error in this measurement because I could only measure when the server stopped sending data. After the response has been fully sent, the Flex client takes 10-12 seconds (seems to depend on system memory utilisation) to parse, E4Xify, bind and update that data into a very simple DataGrid component. The performance of the DataGrid component is actually pretty damn good (even with 10,000+ rows)... no complaints there. I'm *not* complaining about the AS3 E4X parser's performance... it's remarkable that it does it that fast (my perl client using a c-based XML parser library only does it 3.5 times faster on average). I realise that my example is extreme, but in *many* use cases the data takes quite a bit longer to download than to parse... if the whole document must be parsed, an unacceptable amount of time elapses between sending the query, and getting something back to the user. The second important issue is memory usage. Very unscientific viewing of the task manager leads me to believe that the Flash plug-in allocates about 34MB while parsing the XML response. 34MB is not so bad when objectifying a document of that size... but it does have a large performance impact... it makes *much* more sense to parse the document with a constant 4-12kbyte buffered approach. ------------- I'd skip this part if I were you ----------------- Years of service software development has led me to construct my service APIs so that they return data in a streaming fashion - whether the client supports it or not - because it provides much greater flexibility in how that data is used by different client applications. All databases in almost all server-side languages have APIs allowing the user to perform a query then iterate over the result set, only retrieving each row from the database as it is needed. It is well accepted that this results in much higher performance for non-trivial amounts of data. Web-service (say SOAP) libraries that allow streaming are relatively new, but have been available to Java developers for at least 5 years, and to Python developers for at least 3 years. (I use Perl... I actually had to modify SOAP::Lite to make streaming work). ------------------------------------------------------------------- Basically, with large amounts of data.... if you retrieve the full response it takes too long to finish and allocates too much memory... both degrade the user experience. -David.
