A Flash Developer Resource Site

Results 1 to 19 of 19

Thread: [Resolved] [Resolved] [Resolved] [Resolved] [Resolved] [Resolved] [Resolved] [Resolved] [Resolved] [

  1. #1
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112
    So I'm not sure if anyone else has posted anything else like this, but I thought I'd throw it out there.... please remember - I'm not a mathmatician nor a statician (I guess I might not even be a speller )

    With that in mind - here ya go...

    I did some testing (not much) with the 'load' method of the XML object. I started out with the idea that using attributes to describe the data would be faster in Flash's parser than using elements to describe the data. Both the Large and Small tags were repeated either 1 time, 10 times, 100 times, 1,000 times, or 10,000 times.


    Test Machine:
    AMDK6-2 450MHz
    300 MB RAM

    Large:
    < top > < inside1 > a < / inside1 > < inside2 > b < / inside2 > < inside3 > c < / inside3 > < / top >

    Small:
    < top inside1="a" inside2="b" inside3="c" / >

    Large:

    1x=.05 seconds (71 bytes)
    10x=.32 seconds (710 bytes)
    100x=2.68 seconds (7 KB)
    1,000x=49.65 seconds (70 KB) ** Flash gave the error that a script was causing it to run slowly and asked if I wanted to abort - I chose NOT to abort. I let it finish. This effected the total time, but that's kinda the idea.. to see how long it takes to get to the end... **

    Short:

    1x=.05 seconds (42 bytes)
    10x=.06 seconds (420 bytes)
    100x=.31 seconds (5 KB)
    1,000x=3.27 seconds (42 KB) 60% file 6.5% of the time
    10,000x=17.24 seconds (165 KB) 6.034 seconds for equiv file size on Large1,000x

    1,000xLarge and 10,000xSmall:

    A file that was 2.3 times the size, took 65% less time to load. Large had 4,000 'nodes' - Small had 10,000 'nodes'. 2.5 times as many nodes.

    To describe the same amount of data: (different amount of nodes - Large=4,000 Small=1,000)

    1,000xLarge and 1,000xSmall:

    70 KB vs 42 KB
    49.65 vs 3.27

    60% the size 6.5% the time.

    Taking this data and going both backward and forward we can 'assume' that equivalent file sizes will produce between:

    70 KB times 2.357 = 164.99 KB @ 17.24 seconds (Small)
    49.65 times 2.357 = 164.99 KB @ 117.025 seconds (Large) (to load the same size file)
    So.... one boundary for the 'same file size' could be - 85.268% savings on time to load. (Taken off of making the actual file size equivalent.)

    and

    1,000 nodes times 4 = 4,000 nodes @ 49.65 seconds (Large)
    3.27 times 4 = 4000 nodes @ 13.08 seconds (Small) (to load the same number of nodes)
    So.... one boundary for the 'same file size' could be - 73.655% savings on time to load. (Taken off of making the number of nodes in the file equivalent.)



    Well... that's it... yeah I know.. it's sad that this is what I find to do when I want to have fun... Oh well....

    ... and if anybody else has testing thy've done - post it here. Maybe we can try to gather some kind of 'Efficiency' polls.... try to figure out what the best way to do Flash/XML is...

    My contribution: An XML document using attributes to describe data is loaded quicker than an XML document using elements to describe data.

  2. #2
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    I thought attributes loaded quicker, but I just put it down to my imagination. If you think about it, each node is a new XML object, which means that there is a lot more objects created.

    Also I find that attributes are easier to code for in a lot of cases. I use nodes where I need the data repeated any number of times, and I use attributes when there is only one possible value.

    Thanks

    Luke

  3. #3
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Yeah... but...

    Even going with the idea that each node is a 'new object' you can't explain why 10,000 nodes load faster than 4,000 nodes....

    I also think that there is some kind of relationship (detrimental to time) between the number of children a node has. The 10,000 nodes had no children - while the 4,000 node were split up - each main 1,000 nodes had 3 children each... for 4,000 nodes. So there has to be some relationship there.... I wonder if 2,000 nodes with 2 children each would load faster than the 1,000/3 but still slower than the 10,000/0...

    I don't know - maybe I'm all wrong.

  4. #4
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    Hey guys - we need others to run similar tests and post DESCRIPTIVE results and processes.... we need to get a better idea of how to deal with this...

  5. #5
    Well how about extending your test FLA with a output too the consol (trace) and the distribute your test Fla with your XML-Files so others can run the test and copy paste there results to the thread!?

  6. #6
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    Will do. Give me a week...

  7. #7
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    So... I know it's been a LOT longer than a week... but I was going through my old posts.. and noticed several that I hadn't finished.

    Well... I sat down and finished a very simple app. It's all of the Open Source variety.

    Here's what I think would be good to have happen::

    1. Unzip it all to some directory.
    2. Run either of the Standalone EXEs.

    There are comments in the FLA about what's going on, but, the first four buttons run a time test on loading the 'largeXML' format, and 5-9 run time tests on loading the 'smallXML' format. I was planing later on to add functionality so that the 10th button could test a file of the end users choosing - but I haven't yet.

    So... How about we adopt a standard convention for these tests?

    1. Close all Apps that might be running, either in the foreground or in the background, if you can.
    2. Each 'button/test' must be run 10 times in succession.
    3. Take those 10 times and find the average for that 'button/test'.

    When you post your results, please do so as an addition to this thread, and please use this format::

    CPU: speed, type
    RAM: size, type
    HD: capacity, spin rate, transfer rate, type
    Test1: avg. time
    Test2: avg. time
    Test3: avg. time
    Test4: avg. time
    Test5: avg. time
    Test6: avg. time
    Test7: avg. time
    Test8: avg. time
    Test9: avg. time
    Test10: avg. time

    So.... for my computer it would look like this:

    CPU: 450MHz, AMDK6-2
    RAM: 300MB, SDRAM
    HD: 20GB, 7200rpm, ATA66, IDE
    Test1: blah
    Test2: blah
    Test3: blah
    Test4: blah
    Test5: blah
    Test6: blah
    Test7: blah
    Test8: blah
    Test9: blah
    Test10: blah

    For my friends computer it would look like this:

    CPU: 1GHz, PIII
    RAM: 256MB, SDRAM
    HD: 80GB/(2x)40GB, 7200rpm, ATA100, RAID-0 (Striped)
    Test1: blah
    Test2: blah
    Test3: blah
    Test4: blah
    Test5: blah
    Test6: blah
    Test7: blah
    Test8: blah
    Test9: blah
    Test10: blah


    Does that make sense???

    I'm not sure, but I think that's all we really need to know about hardware... if anybody else has suggestions - let us know.

    OH - and the link to DL the Zip file::

    http://www.curtismorley.com/x/timeTe..._childNode.zip

    Test away!

  8. #8
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    OK, I didn't read Vaykents post real well about what I was or was not suppose to do as I did the testing offline. I found a bunch of typical Macs as I figured there would be a heap of people able to post about there highend machines.

    I also tested in a browser and running as an app. The times are seperated by spaces. The 4th test ussually timed out and seemed to crash the flash player probably not enough memory.
    This didn't occur in OS-X as Flash runs native and therefore has virtual memory.

    All times in MilliSeconds

    Mac G3 Desktop 233mhz
    768mb of Ram 40gb HD 7200RPM
    Three Tests: OS9.0 As App, IE5.0 (latest Patch) OS9.0, MacOSX.1 IE5.1

    Test 1: 50, 117, 100
    Test 2: 200, 367, 433
    Test 3: 2083, 12266, 3833
    Test 4: Aborted
    Test 5: 33, 84, 50
    Test 6: 66, 117, 100
    Test 7: 283, 433, 483
    Test 8: 2450, 433, 483
    Test 9: Aborted


    iMac DV 500mhz G3
    330mb of Ram, 20gb HD 5200RPM
    Three Tests: OS9.0 App, IE5.1 OS X.1, OSX.1 App (running in classic)

    Test 1: 33, 50, 50
    Test 2: 133, 250, 133
    Test 3: 1050, 1817, 1066
    Test 4: Aborted, 25533, Abort
    Test 5: 83, 50, 16
    Test 6: 83, 50, 33
    Test 7: 166, 250,150
    Test 8: 1183, 2133, 1283
    Test 9: Aborted

    Interesting results with tests 5,6&7 on the iMac as this is running in classic mode which is basically an emulator of first tests and you would expect it to be *much* slower. I did it purely out of interest. I was expecting the results to be a quarter of the intitial results from running classic straight. Probably a sign of the 'optimisations' that Apple did on OS-X.1 in classic mode.

    Thanks

    Luke


  9. #9
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    Sweet. Thanks a bunch. I don't have a Mac on hand to test on... I'm hopin' a lot of other people will download this and try it on their machines as well...

  10. #10

    Re: Yeah... but...

    Hello,

    I got some note on the 10000 node version being faster than a 4000 node version. I think it just depends on the parsing algorithm. I guess it's the recursion that's slowing the thing down. While parsing the non-attribute version, the parser has to keep track of a node stack, because he will repeatedly be parsing child nodes (though the stack will never contain more than 1 node, the top-level one). In de attribute-version, no recursion is present, since there are no child nodes, so the node stack will always be empty. Now, without recursion and without the need of pushing things on and popping things of a stack, the parsing might deliver it's work a whole lot faster... appearantly.

    I hope I make any sense...

    Grtz,

    Grimz

  11. #11
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    So... you're saying that you have a parser that runs faster for certain types of structures??

    Great! - Could we see some code?

  12. #12
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    I don't think he has code for a different parser just telling you how the Flash parser works.

    BTW what are the number for Flash MX running these tests?

    Thanks

    Tupps


  13. #13
    The bare parser may perform equally in all parsing contexts, but it's the attached code (the code that gets executed when a rule is matched) that may slow it down. So please don't be sarcastic, I'm only trying to get my finger at the problem. Anyway, it doesn't really matter. We know that nodes are slower than attributes, so I'll shut my mouth right here.

    Grimz

  14. #14
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    This is the code that is used for the parsing:

    function go(xmlDocumentURL){
    _root.xmlHolder = new XML();
    _root.xmlHolder.onLoad = stopTimer;
    _root.xmlholder.load(xmlDocumentURL);
    }

    function stopTimer(){
    _root.loadTime = getTimer() - _root.startTime;
    trace("Ended.");
    }

    As you can see this is purely testing the XML loading, it is not actually doing any parsing in Flash.


  15. #15
    Maybe I express myself somewhat unclear, but I did not mean that you do the parsing yourself, but I was talking about Flash's parsing algorithm. I just took a guess at how Flash might parse XML (as I have implemented a very simple XML parser once in C++). And from the documentation you get to know that "the XML data is not parsed until it is completely downloaded", so the load method also parses.
    I haven't tested all examples yet on Flash MX, but I guess that must be somewhat faster, as MM claims to have optimized the XML parser.

    Grimz

  16. #16
    Senior Member
    Join Date
    Feb 2001
    Location
    Provo, Utah
    Posts
    1,112

    Uhh...

    MM cliams to have optimised... yeah. I'd say so!

    The difference from 5 to MX is the same as the difference from 'not loading' to 'finished in 1/10th of a second'.

    Yeah... I'd say they optimised!

  17. #17
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035

    Bringing it all back on topic....

    I know the Flash-MX is fast, but what are the number for Flash MX running these tests?

    Thanks

    Luke

  18. #18
    Member
    Join Date
    Mar 2002
    Posts
    69
    Hi,

    I ran the tests on my computer and here are the results and boy can you see the difference between flash 5 vs MX.

    FlashMX is the first number, the numbers in brackets are the results of the flash 5 exe that was included in the download.


    CPU: 1.4 Ghz AMD Thunderbird
    RAM: 512MB, 266DDR RAM
    HD: 40GB, 7200rpm, ATA100, IDE
    Test1: .8 (19.8)
    Test2: 1 (59.1)
    Test3: 5.5 (425.7)
    Test4: 64.6 (8700.4)
    Test5: .8 (15.9)
    Test6: .9 (20.3)
    Test7: 2.8 (62.1)
    Test8: 23.9 (635)
    Test9: 557.3 (15480.2)

    Test #9 came up with the "script running slowly" error three times out of 10 with flash 5.

    -thurston

  19. #19
    Senior Member tupps's Avatar
    Join Date
    Jan 2001
    Location
    Melbourne
    Posts
    2,035
    I knew it was faster, 20~30 times is impressive. From what I hear a lot of the string handling functions have been written as native code, so that is probably where they got there speed.

    Will put some tests up from my Mac in the next couple of days.

    Thanks

    Luke

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  




Click Here to Expand Forum to Full Width

HTML5 Development Center