11 Replies Latest reply on Jun 20, 2011 2:05 PM by edb00

    D11.5 so incredibly slow in authoring

    edb00

      Just set up an MX 2004 project that does a long import from a text file ( 9.4 MB with 170 individual records within it). The import runs acceptably in authoring or as an app in Mx 2004 ( 5-10 min ) but is unbelievably slow ( 30+ min ) in D11.5 authoring.

       

      I just have the trial version for now so I'm wondering if performance will improve if made into an app.

       

      Mac OSX 10.6.7

       

      Any thoughts?

       

      Thanks

        • 1. Re: D11.5 so incredibly slow in authoring
          jchunick Level 2

          First, what is the productBuildVersion and productVersion (ie. put the environment in the message window)?

           

          Secondly, do you have control on how this file is structured?... btw, if you have that many records with that amount of data why are you using a flat file and not a database? There's the SQLLite DB Xtra from Valentin which is compact and wonderfully portable: http://staff.dasdeck.de/valentin/xtras/sqlite_xtra/

           

          Lastly, you have to remember that D11.5 now supports unicode and this itself will slow down certain processes.

          • 2. Re: D11.5 so incredibly slow in authoring
            edb00 Level 1

            [#shockMachine: 0, #shockMachineVersion: "", #platform: "Macintosh,Intel", #runMode: "Author", #colorDepth: 32, #internetConnected: #online, #uiLanguage: "English", #osLanguage: "English", #productBuildVersion: "593", #productVersion: "11.5", #osVersion: "Macintosh OS 10.6.7", #licenseType: "Trial", #trialTime: 0]

             

            I have complete control of the design and function of this project.

             

            The data are being transferred from an online SQL database to this Utility for analysis and manual scoring. The structured text file is created online from the database and then downloaded to the users computer. The user can then import the data from the file into the Utility where it is loaded into a variety of cast members for comparison to standards. Manual scoring can also be done. The Utility also provides statistical information on the performance of the individuals compared to the whole group.

             

            The file is read into a variable all at once. (Earlier attempts to read the file in pieces where not successful and slower)

             

            The main delay seems to be in parsing the data and creating the cast members to hold it. The analysis seems to occur just as fast as it always has. Saving the analysis and the cast containing the new members is somewhat slower than previous versions.

             

            This is not a new project it has been used for many years with success.

             

            Thanks

            • 3. Re: D11.5 so incredibly slow in authoring
              jchunick Level 2

              1. Go to Help --> Updates and see about getting the newest updates for your version... Edit: not sure if it will run in trial mode.

              2. You should double-check some stuff as it shows your #licenseType is "Trial" and your #trialTime is 0, so something looks a bit buggy, ie. it shouldn't be running still. Edit: I see in your first post you do have the trial version... hmmm... I guess they are not using the #trialTime property, so disregard this #2.

              3. I'm a bit confused because in your original post you only mention that importing data from a text file is slower... however, now you're indicating that it's all the stuff you're doing after the importing of the data is slower. Getting information piecemeal makes it difficult to troubleshoot... is there an example file you can create to illustrate the slowdowns you are seeing?

              4. Also, have you tried to read the file using the ByteArray Object?
              Methods: http://help.adobe.com/en_US/Director/11.5/UsingScripting/WSF564D6B0-201D-43f0-ABEB-17B2F9F FA43B.html

              http://help.adobe.com/en_US/Director/11.5/UsingScripting/WSF564D6B0-201D-43f0-ABEB-17B2F9F FA43B.htmlProperties: http://help.adobe.com/en_US/Director/11.5/UsingScripting/WS010BB656-AA02-4392-8B44-B05928C DEF69.html

              Operator Summary: http://help.adobe.com/en_US/Director/11.5/UsingScripting/WS8CC4DE01-66F7-409b-8F23-2542DD9 32638.html

              • 6. Re: D11.5 so incredibly slow in authoring
                edb00 Level 1

                Tried sending this twice fram my mail client -- no luck
                Will try in forum
                On Jun 16, 2011, at 2:10 PM, jchunick wrote:

                1. Go to Help --> Updates and see about getting the newest updates for your version.
                Now   [#shockMachine: 0, #shockMachineVersion: "", #platform: "Macintosh,Intel", #runMode: "Author", #colorDepth: 32, #internetConnected: #online, #uiLanguage: "English", #osLanguage: "English", #productBuildVersion: "612", #productVersion: "11.5.8", #osVersion: "Macintosh OS 10.6.7", #licenseType: "Trial", #trialTime: 0]

                2. You should double-check some stuff as it shows your #licenseType is "Trial" and your #trialTime is 0, so something looks a bit buggy, ie. it shouldn't be running still.
                Says I have 88 days left. There is the annoying thing on startup of Director that it has found duplicate xtras -- mostly filters that I can only find on my machine in a Flash folder see separate post.

                3. I'm a bit confused because in your original post you only mention that importing data from a text file is slower... however, now you're indicating that it's all the stuff you're doing after the importing of the data is slower. Getting information piecemeal makes it difficult to troubleshoot... is there an example file you can create to illustrate the slowdowns you are seeing?
                As is often the case, describing a problem to someone helps focus and crystalize the real problem.
                Importing data is a one click thing in this app but involves a lot of steps in the one script that does it.
                The speed has not improved.
                Curiously the text file must be Unicode to work at all. If not high ASCII characters in the data interfere with parsing the text by item delimiter.

                So it would appear the problem lies in ether parsing the text or creating the multiple new cast members.
                Text is split up by setting item delimiter then get item x of the full data
                change delimiter getting items 1 to n 
                with each item split on a different delimiter to give cast member name and the text to go in it
                create the cast members
                go back to get next record from the full data
                Or creating new cast members ash adding text to them is just slow -- in this case it creates about 7200
                As for creating a demo project I'll consider that maybe not so hard?
                Thanks

                • 7. Re: D11.5 so incredibly slow in authoring
                  edb00 Level 1

                  I've created a simple project that just creates new cast members and puts some text in.

                   

                  Creating 7500 cast members zips along fine.

                   

                  putting the same 200 char string in each after its created not bad.

                   

                  Increase the string length to a paltry 2000 characters very slow

                  Increase the string length to 20000 and it appears to frozen though i'm sure its really working away

                   

                  Most of my data is fairly compact but a couple of items in each record set can easily get to 5 or 6000 characters.

                   

                  How could something as basic as putting text into a cast member be so slow???

                   

                  Here's my test script.

                   

                  on mouseUp

                    temp = empty

                    tempInc = "aaaaaaaaaaaaaaaaaa"

                    repeat with j = 1 to 100

                      temp = temp && tempInc && j

                    end repeat

                   

                    put temp.char.count

                   

                    nextEmpty = 3

                    fileItemCount  = 100

                    groups = 20

                   

                    repeat with i = 1 to groups

                      member("progress").text = "Group" && i

                      updateStage

                   

                      repeat with itemNum = 2 to fileItemCount

                   

                        new(#field, member nextEmpty of castlib "record")

                        the name of member nextEmpty of castlib "record" = itemNum && "aMember"

                        member(nextEmpty, "record").text = temp

                        nextEmpty = nextEmpty +1

                      end repeat

                   

                    end repeat

                   

                  end

                  • 8. Re: D11.5 so incredibly slow in authoring
                    jchunick Level 2

                    I ran your code both on D10 and D11.5 and it took 4426ms and 9685ms respectively... that's about 2.2x longer in D11.5 which doesn't seem too unreasonable when dealing with Unicode (UTF-8, multi-byte) characters.

                    • 9. Re: D11.5 so incredibly slow in authoring
                      edb00 Level 1

                      I doubt if my customers would see it that way.

                       

                      Anyway there is a solution use text cast members instead of field cast members.

                       

                      My sample script runs in 51 ticks using text members vs 3322 with field members.

                      • 10. Re: D11.5 so incredibly slow in authoring
                        jchunick Level 2

                        edb00 wrote:

                         

                        I doubt if my customers would see it that way.

                         

                        Anyway there is a solution use text cast members instead of field cast members.

                         

                        My sample script runs in 51 ticks using text members vs 3322 with field members.

                        Where's the smiley?... because I'm just trying to help and your comment about it being incredibly slow sounds a lot worse than 1/2 as fast. Of course, my comment is strictly meant to point out that you are now dealing with a system that has to be able to deal with multibyte characters so the underlying code could easily be slower; it was certainly not meant to address how our customers would perceive things.

                         

                        Anyhow, glad you found a solution.... I wonder if unicode has some (fixable) performance issues when used with fields vs. text members?...

                        • 11. Re: D11.5 so incredibly slow in authoring
                          edb00 Level 1

                          Sorry didn't mean to disparraging.

                           

                          Fields were always the simple no frills cast members for text. Not anymore I guess.

                          Changed over the full app from fields to text for the data and it actually seems to run faster than the MX version.

                           

                          Thanks

                           

                          Now if I could just track down the duplicate xtra message when D11.5 starts up.