Alpha Software Mobile Development Tools:   Alpha Anywhere    |   Alpha TransForm subscribe to our YouTube Channel  Follow Us on LinkedIn  Follow Us on Twitter  Follow Us on Facebook

Announcement

Collapse

The Alpha Software Forum Participation Guidelines

The Alpha Software Forum is a free forum created for Alpha Software Developer Community to ask for help, exchange ideas, and share solutions. Alpha Software strives to create an environment where all members of the community can feel safe to participate. In order to ensure the Alpha Software Forum is a place where all feel welcome, forum participants are expected to behave as follows:
  • Be professional in your conduct
  • Be kind to others
  • Be constructive when giving feedback
  • Be open to new ideas and suggestions
  • Stay on topic


Be sure all comments and threads you post are respectful. Posts that contain any of the following content will be considered a violation of your agreement as a member of the Alpha Software Forum Community and will be moderated:
  • Spam.
  • Vulgar language.
  • Quotes from private conversations without permission, including pricing and other sales related discussions.
  • Personal attacks, insults, or subtle put-downs.
  • Harassment, bullying, threatening, mocking, shaming, or deriding anyone.
  • Sexist, racist, homophobic, transphobic, ableist, or otherwise discriminatory jokes and language.
  • Sexually explicit or violent material, links, or language.
  • Pirated, hacked, or copyright-infringing material.
  • Encouraging of others to engage in the above behaviors.


If a thread or post is found to contain any of the content outlined above, a moderator may choose to take one of the following actions:
  • Remove the Post or Thread - the content is removed from the forum.
  • Place the User in Moderation - all posts and new threads must be approved by a moderator before they are posted.
  • Temporarily Ban the User - user is banned from forum for a period of time.
  • Permanently Ban the User - user is permanently banned from the forum.


Moderators may also rename posts and threads if they are too generic or do not property reflect the content.

Moderators may move threads if they have been posted in the incorrect forum.

Threads/Posts questioning specific moderator decisions or actions (such as "why was a user banned?") are not allowed and will be removed.

The owners of Alpha Software Corporation (Forum Owner) reserve the right to remove, edit, move, or close any thread for any reason; or ban any forum member without notice, reason, or explanation.

Community members are encouraged to click the "Report Post" icon in the lower left of a given post if they feel the post is in violation of the rules. This will alert the Moderators to take a look.

Alpha Software Corporation may amend the guidelines from time to time and may also vary the procedures it sets out where appropriate in a particular case. Your agreement to comply with the guidelines will be deemed agreement to any changes to it.



Bonus TIPS for Successful Posting

Try a Search First
It is highly recommended that a Search be done on your topic before posting, as many questions have been answered in prior posts. As with any search engine, the shorter the search term, the more "hits" will be returned, but the more specific the search term is, the greater the relevance of those "hits". Searching for "table" might well return every message on the board while "tablesum" would greatly restrict the number of messages returned.

When you do post
First, make sure you are posting your question in the correct forum. For example, if you post an issue regarding Desktop applications on the Mobile & Browser Applications board , not only will your question not be seen by the appropriate audience, it may also be removed or relocated.

The more detail you provide about your problem or question, the more likely someone is to understand your request and be able to help. A sample database with a minimum of records (and its support files, zipped together) will make it much easier to diagnose issues with your application. Screen shots of error messages are especially helpful.

When explaining how to reproduce your problem, please be as detailed as possible. Describe every step, click-by-click and keypress-by-keypress. Otherwise when others try to duplicate your problem, they may do something slightly different and end up with different results.

A note about attachments
You may only attach one file to each message. Attachment file size is limited to 2MB. If you need to include several files, you may do so by zipping them into a single archive.

If you forgot to attach your files to your post, please do NOT create a new thread. Instead, reply to your original message and attach the file there.

When attaching screen shots, it is best to attach an image file (.BMP, .JPG, .GIF, .PNG, etc.) or a zip file of several images, as opposed to a Word document containing the screen shots. Because Word documents are prone to viruses, many message board users will not open your Word file, therefore limiting their ability to help you.

Similarly, if you are uploading a zipped archive, you should simply create a .ZIP file and not a self-extracting .EXE as many users will not run your EXE file.
See more
See less

Script causing browser to run slowly

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #76
    Re: Script causing browser to run slowly

    Talk about being careful..
    Unfortunately, some of the comments can be misleading at best or simply uninformed at worst.
    If the WIKI worked and the documentations was up to standard and the processes well tested we would not need a message board to solve problems.. SO don't go discrediting people trying to help solve a problem by intimidating them.. or undermining them.
    Insanity: doing the same thing over and over again and expecting different results.
    Albert Einstein, (attributed)
    US (German-born) physicist (1879 - 1955)

    Comment


      #77
      Re: Script causing browser to run slowly

      The issue is Carol has a problem with A5 and for some time now and you can't fix it. Do you not see what I see on the forum, issue after issue, are they issues or are we all stupid in your mind.
      Last edited by peteconway; 03-15-2012, 10:46 PM.
      Insanity: doing the same thing over and over again and expecting different results.
      Albert Einstein, (attributed)
      US (German-born) physicist (1879 - 1955)

      Comment


        #78
        Re: Script causing browser to run slowly

        You are out of your depth here.

        Carol's problem is well understood by Carol now. It is specific to IE8 and it is because she is opening too many Grids and using too much memory. I don't see how the fact that she is consuming too much memory in IE8 has anything to do with the wiki.

        I was simply stating that you made a comment that was wrong and telling people to ignore the incorrect information you were posting. I pointed out why you were wrong in a set of videos that clearly explained the issues and made it very clear exactly why your comments were uninformed.

        Comment


          #79
          Re: Script causing browser to run slowly

          Well 73 records in a table in a sample having nothing to do with a real world environment is not what I would call conclusive, you are right the WIKI has nothing to do with anything. And you are in no position to tell me I'm out of my depth,
          It is specific to IE8 and it is because she is opening too many Grids and using too much memory.
          why does Alpha let her do this, are we now limited to the number of grids that can be opened.
          Insanity: doing the same thing over and over again and expecting different results.
          Albert Einstein, (attributed)
          US (German-born) physicist (1879 - 1955)

          Comment


            #80
            Re: Script causing browser to run slowly

            73 records in a table? what's this got to do with anything? it appears that you did not really understand the points made in the video. the number of records in the table on which a grid is based has absolutely nothing to do with how much memory the grid consumes. a grid that is based on a table with 10 records and a grid based on a table with 10,000,000 records consume the same amount of memory on the client side.

            Comment


              #81
              Re: Script causing browser to run slowly

              So if Carol had 20 grids with 20 records in each and 20 grids with 10,000,000 in each Alpha would perform the same (ok memory would be the same) but would performance and user experience be the same. Also
              why does Alpha let her do this, are we now limited to the number of grids that can be opened.
              what is the limit. You are talking about the Grid alone as the issue - it's like saying what's heavier an empty bucket or a full bucket, your answer would be they are the same, it's the water that's heavier. Anyhow enough time wasted at this depth, going back to normal depth. Thanks for responding.
              Insanity: doing the same thing over and over again and expecting different results.
              Albert Einstein, (attributed)
              US (German-born) physicist (1879 - 1955)

              Comment


                #82
                Re: Script causing browser to run slowly

                Speculations about performance and what impacts performance make for interesting coffee house talk, but mean very little in the real world. Here are a few facts garnered from real world applications actually being used on a daily basis.

                A grid that displays 10 records based on a modern SQL database like MySQL, MS SQL Server, or Oracle will typically run at about the same speed if the background table has 100 records or 1 million. The grid only requests the first 10 records. Any slowdown is caused by a slower query time in the database engine with larger tables, often the result of poorly designed indexes in the database.

                Some database engines are very fast, such as MySQL, SQL Server and other enterprise systems, and some are slow, like Access.

                For example, one production system running on SQL Server 2008 R2 has just under 1 million records in a primary SQL view (which has 22 linked tables in the view). A row sort on an indexed field with 12 rows being shown can take less than 600ms. In this case, the client and server are separated by almost 2000 miles across a typical high speed internet connection.

                The second page (page 2 of whatever) and any subsequent page will run a bit slower as the second page will return 24 records and show the last 12, the third page 36 records and show the last 12 and so on. But since the data set is being manipulated on the server and only 12 records are being sent back and filled by Ajax, the speed doesn't change much.

                Going from 10 rows to 20 rows being shown will slow the grid / dialog / page as more data is being transmitted across the connection between the server and the client. The first request for the grid has to download all of the grid HTML code, so more rows will require more HTML and the load will be slower. This is true if the grid is directly on a page or loaded from some Ajax call. However, if the grid is cached, subsequent calls don't load the component code, and speed is dependent on the amount of data being transmitted.

                A grid that has 50 fields will be slower than the same grid reduced to 10 fields. This is not only because the grid HTML is larger, but because every request for data has to transmit a lot more data. This impact is sometimes not obvious as a grid may have tabbed sections that only show a few fields on each tab, but when deconstructed, the single grid may actually have a large number of fields spread across many tabs.

                While JavaScript is very fast, the more that is added to a grid / dialog / page, the longer it takes for the browser to process it. Some JavaScript engines are very good, and some are not. For example, Chrome is very fast for some JavaScript operations, but as the number of operations increase, eventually it begins to slow until it is noticeably slower than even IE. All client side operations run using JavaScript, so as more actions are added, such as client side show/hide, enable/disable, and conditional style expressions, the structure will begin to slow as the client JavaScript engine has to do more work. If the browser itself is a bit slow, the impact can be very noticeable.

                Often the amount of data being transmitted isn't obvious, such as using dropdowns with a large number of records.

                Server side actions are typically much faster than client side actions.

                An editable grid is slower than a read only grid, mainly because there is less HTML and less JavaScript to load and run the page. This is true even if the grid has an editable detail view.

                A tabbedUI with one grid will run at almost the same speed as one with 10 grids. The initial load will be slightly slower as more HTML is needed on the page to handle more grids, but since the grids are only opened by request, the actual time to open each grid doesn't change.

                So why are some applications fast and some slow?

                Assuming the environment is the same - same internet speed, same server processing speed, same database, real world testing has shown it is almost entirely the result of design decisions.

                More rows being displayed will be slower
                More fields per record will be slower
                More client side operations per record will be slower

                This is true if the page is built from an Alpha component or hand coded from HTML. If speed is the primary goal, then simplicity should be the axiom.

                One real world application has been in production use for over a year with almost 1 million rows in one primary table and 4 million in some secondary tables. The application has almost 300 tables and views, more than 230 grids, and more than 300 pages. The slowest grid shows a single record and takes under 1.5 seconds to load. Some complex queries can take some seconds to complete, but the limiting factor is not Alpha, but the speed of the query in the data engine.

                At the other extreme, another real application built in another product displayed a simple list with 200 rows, with each row having 20 editable fields with 4 fields having dropdowns with about 200 rows per dropdown. That single page took almost 25 seconds to load. It wasn't because the tool used to build and run the page was slow (it was running on an IIS server), or the number of records was large (the table only had 200 records) but because the design decisions were poor.

                These results are not based on theoretical concepts or hypothetical applications, but were obtained from careful and extensive testing of real applications.

                Comment


                  #83
                  Re: Script causing browser to run slowly

                  Jerry, many thanks for the summary, this message was not really discussing speed until Selwyn's video's highlighted speed, 148ms etc. but the message generated by IE8 that Script causing browser to run slowly - The answer was ..to quote Selwyn,
                  Carol's problem is well understood by Carol now. It is specific to IE8 and it is because she is opening too many Grids and using too much memory.
                  - all I was asking is why should she waste so much of her valuable time messing around with issues beyond her control that don't work. The Wiki was mentioned.. just where in the Wiki would Carol find the answer to the problem, where did Selwyn get the answer to the problem, do you all use the same Wiki as us, or is there another... for that matter as Selwyn put it "I'm out of my depth here" - well why is the issue so deep in the first place. Where is the documentation that would get me into a better depth? Once again thanks for the summary - please put it in the Wiki somewhere people will be able to find it. It may surprise you, I do understand the issue, you keep pushing the line of developer like
                  real world testing has shown it is almost entirely the result of design decisions.
                  Help those decisions with meaningful supporting documentation from Martin's dept. and we will all be happy. - Thanks.
                  Insanity: doing the same thing over and over again and expecting different results.
                  Albert Einstein, (attributed)
                  US (German-born) physicist (1879 - 1955)

                  Comment


                    #84
                    Re: Script causing browser to run slowly

                    All of this information is very informative and makes sense. The one thing I'm still not clear on is.... what is it about turning on the date pickers that causes my grid to produce slow script errors when opening it in a tabbed ui? I understand that opening it in a tabbed ui means that there is a new instance of the grid each time I open it and this helps produce the slow script error. I also understand that opening it in a cached window means that I am not opening a new instance of the grid each time, thus helping to prevent the slow script error. I would really like to open this grid in a tabbed ui, and I'd like to have the date pickers... but maybe I will have to give up on that since so many of my users will probably be using IE 8?
                    Carol King
                    Developer of Custom Homebuilders' Solutions (CHS)
                    http://www.CHSBuilderSoftware.com

                    Comment


                      #85
                      Re: Script causing browser to run slowly

                      Selwyn you said
                      Carol's problem is well understood by Carol now. It is specific to IE8 and it is because she is opening too many Grids and using too much memory.
                      What you didn't tell me (it seems) was the solution (if one exists) was not well understood by Carol and she is no better off.
                      Insanity: doing the same thing over and over again and expecting different results.
                      Albert Einstein, (attributed)
                      US (German-born) physicist (1879 - 1955)

                      Comment


                        #86
                        Re: Script causing browser to run slowly

                        Although I started this thread to be about slow script errors, the execution of queries in Access has been brought up. So, in my overall pursuit of solutions to speed, we ran a test that I show in the following video. We made a simple Alpha page that executes the query without a grid and found that this rather complex query takes anywhere from 2.5 to 3 seconds to execute. I have tried same using MySql and did not notice much difference. When I put this query into a grid and run it without totals, it generally takes 4.5 to 5 seconds to execute the query... although in my video it decided to take anywhere from 8 to 11 seconds to execuite for some reason. I guess what I'd like to understand is what the grid is doing to slow down the query, and what I might need to eliminate from the grid. I understand that it WILL slow down if I use summary totals because the query will have to execute a second time to display the totals, but I don't have summary totals on the grid right now. Here is video of our test: http://screencast.com/t/RoOOKdSJ1jb
                        Last edited by kingcarol; 03-16-2012, 10:33 AM.
                        Carol King
                        Developer of Custom Homebuilders' Solutions (CHS)
                        http://www.CHSBuilderSoftware.com

                        Comment


                          #87
                          Re: Script causing browser to run slowly

                          Pete, I do understand that the slow script errors is a result of IE 8 and opening my grid in a tabbed ui, which means it is not cached. I think that is what Selwyn meant by my understanding. What I'm not clear on is why turning on the date pickers in the grid opened in tabbed ui triggers the slow script errors and turning the date pickers off means the script errors go away.
                          Carol King
                          Developer of Custom Homebuilders' Solutions (CHS)
                          http://www.CHSBuilderSoftware.com

                          Comment


                            #88
                            Re: Script causing browser to run slowly

                            Sorry to interject, but this is a great thread! Drama, tension and interesting information. Who said database development was boring?

                            Comment


                              #89
                              Re: Script causing browser to run slowly

                              All,
                              I was wondering, does the A5 Date Picker use jQuery?

                              A google search on "jquery ie8 browser run slowly" reveals some rather interesting messages:

                              http://bugs.jquery.com/ticket/7341
                              http://stackoverflow.com/questions/6...ly-alert-in-ie
                              http://stackoverflow.com/questions/8...-slowly-on-ie8
                              http://stackoverflow.com/questions/4...ry-ui-nyromoda

                              If jQuery is being used for the Date Picker then is it being used to modify controls by specific control ID or is it scanning all controls? If scanning ALL controls then does it do it one time or does it repeat for each date field?

                              When I open a tabbed UI panel in Firefox and view its source, I can see the navigation buttons from the tabbed-UI interface as well as the controls on the grid. If jQuery is inadvertently being used to scan all controls then a Tabbed-ui with a lot of buttons would perform slower than a minimal tabbed-ui. The links above clearly demonstrate that IE8 can be particularly slow with jQuery and that sometimes workarounds can be found.

                              -Rich

                              Comment


                                #90
                                Re: Script causing browser to run slowly

                                JQuery is not being used for our date pickers.
                                We have made a change to the date picker code to specifically accommodate the fact that IE8's Javascript engine is not very efficient. This will be in the next update.

                                Comment

                                Working...
                                X