Speed of a5w pages?

[B.B.Bongers]

Hi guys,

I must conclude that a5w pages are rendered slow in v7.
Will Alpha improve this performance issue with the next version(v8)?

Specifations
DB:Alpha dbf tables/max records 150 in a table
Components: grids and some dialogs
WAS running@Windows XP PRO/2.4 Ghz/internal memory 1.5 GB.
Browser: Firefox and MS IE

Kind regards,

Brendo Bongers

[B.B.Bongers]

Re: Speed of a5w pages?

Nobody?

[rleunis]

Re: Speed of a5w pages?

Brendo,

I read in an email of Alpha5 that once Ajax techniques are implemented, the raise in performance will be dramatic...I hope this or parts of it will be implemented in V8. regards, Ron

[B.B.Bongers]

Re: Speed of a5w pages?

Thanks Ron.

I know that Alpha is introducing AJAX.
One of the benefits of AJAX is that it use less bandwith by reducing full requests to the server.
But all webbased languages(ASP/PHP/ASP.NET/JSP) will gain performance when using AJAX. So that's a general benefit.

I think that Alpha could gain much more performance even without the use of AJAX by tracking down the bigger/main performance issues in V7.

Kind regards

Brendo

[Peter.Greulich]

Re: Speed of a5w pages?

I think that Alpha could gain much more performance even without the use of AJAX by tracking down the bigger/main performance issues in V7.

One of the issues with Alpha's slowness on the web is that it re-compiles the HTML on runtime - everytime you load or reload a page. This is being changed so the HTML will be created at design time (hopefully for v8), not runtime.

If you handcode the HTML, etc. yourself, Alpha is very fast, as Cal Locklin has demonstrated. Of course, you don't want to hand code, so hopefully the above will address that issue.

[B.B.Bongers]

Re: Speed of a5w pages?

Thanks Peter

I hope they will improve this in v8!
Exactly, the benefit of the components is that it saves developmenttime and it's possible to build webpages without high level knowledge of HTML/CSS/javascript.
But if it has too much impact on performance, it loses her benefit.
Due to the fact that nowadays endusers are not patient enough to wait on slow loading pages.

[Peter.Greulich]

Re: Speed of a5w pages?

Due to the fact that nowadays endusers are not patient enough to wait on slow loading pages.

Including me! :)

[Steve Wood]

Hand coding

Speculating on this subject of hand coding, I wonder if any of the following increase performance short of actually hand coding from scratch:

1) Develop the component as normal, then strip out any unused xbasic? By unused I mean anything that sets a value that the Alpha interpreter would consider default; or remove the many left over references that tend to build up as one switches from one setting to another (e.g. "DropdownBox.Choices =" still exists if you change the field from choice to textbox).

2) Running something like TidyHTML that is supposed to clean up html, removing redundant tags, etc.

3) Selective modification of the A5W page code such as removing a runtime call to the A5W interpreter and replacing with a block of code (ala design time versus runtime HTML).

4) Selectively remove (simple Delete keystroke) sections of the component that appear on the A5W page when the component is inserted (Echo, Update Errors, Search, Data, Details).

My uninformed question is, "what one or two things can I do to get X% greater speed". If I could make the same repetitive change to all of my pages, and that gained me 20%, I'd spend the time, develop a protocol.

[JerryBrightbill]

Re: Speed of a5w pages?

I posted this a while back, but it still applies

Speed in Web Pages

To expand on that post, there are some other simple things that will increase speed. First, avoid multi-row grids with dropdowns. Every dropdown has to be populated, which slows the page and adds a lot of text to the page. Use lookups where possible.

Avoid dropdowns with large numbers of options. If the number of options is more than about 100, the amount of text on the page becomes large enough to have significant impacts on speed.

Avoid calculated fields unless they are simple calculations based only on the fields for the tables linked to the component. Calculated fields slow any layout, including the desktop. Because of the nature of the browser environment, that speed impact is more noticable. If you need a large number of calculated fields, it may be better to put the calculated fields in the table, rather than calculate them at runtime. This is different than the desktop where calculated fields on a layout are more common.

Avoid grids with many lines, especially editable grids. Avoid large numbers of fields in grids. An editable grid stores the data in 2 places. First, the data is stored in the visible fields. But as mentioned in the other post, all of the editable data for all lines is also stored in a hidden field for Optimistic Record Locking to check if the data on the page was changed by another user prior to committing the data. This hidden field can get quite large if there are a large number of editable rows. Sometimes reducing the number of rows can have a major impact on speed. I typically limit any editable grid to 10 rows or less. If the grid is view only, the impact from large numbers of rows is less, but still a concern.

Avoid extensive use of inline styles. If you need a change that will impact all style elements on a page, such as changing the font size, create a new custom style. A CSS file is loaded once, whereas styles on a page just add overhead on every page load. If you need to change the width of a column in a tabular grid, set the width of the header, not the individual cells. This will set the width of every cell in the column without adding any inline style code to every cell.

Keep pages simple. Use Quick Search in place of search sections if possible.

Avoid multiple components on the same page. Every component has to be loaded and run. As you add more components, that slows the page. The exception is the nav component which is very fast.

As Steve pointed out, remove any unnecessary code from a page. I recently saw a page that was very slow because the same component loaded multiple times, but only displayed once. The problem occured because the developer had added the component, then removed it in the WYSIWYG mode, and then added it again without saving the page - multiple times. Every time a component is added, code is added to the source of the page to load and run the component. If you remove the component in the WYSIWYG mode, that code is not initially removed. If you save the page at that point, the save action checks for orphaned code and will remove it. If you don't save, but just add the component again, you could end up with duplicated code, which will cause a noticable slowdown

Anything you can do to reduce the code on any html page will improve speed. Most of the tips above apply to any web page, not just Alpha components.

[Steve Wood]

Re: Speed of a5w pages?

Jerry - so nothin' I can do, eh.

Is it possible to quantify - which one or two are the biggest bang for the buck? Can you estimate (theoretically) if one did ALL of the items you list on an "average" page*, that the result would be in the neighborhood of 2%, 10%, 50% or 100% faster. If, for example, the best improvement possible is less than 20%, it probably won't make sense to bother, unless there is one or two items that make up the bulk of that percent.

I may try to categorize these in to a check list or something.

* An average page would have a single component and a nav, and a little of each of the problem code you referred to, with the exception of the egregious multiple ghost components resulting from add/remove/add without saving.

[JerryBrightbill]

Re: Speed of a5w pages?

Anything done to reduce the page size will normally increase speed. While it is very difficult to put a number on any change, probably the biggest single impact comes from reducing the size of editable grids. But add up enough little things and the speed impact can be very noticeable. Also, there have been some changes in recent V7 builds to improve component speed, particularly with larger and more complex components. Some of these changes are on the order of .2 to .3 seconds improvement just in the time to load the component parameters, which on a percentage basis is huge.

[B.B.Bongers]

Re: Speed of a5w pages?

Anything done to reduce the page size will normally increase speed.

A lot of users have a fast internet/lan connection. In the middle 90's we had 56 k modems:)
Reducing the size of a webpage by optimize techniques will not make a major difference I think.
Crapy HTML code is not nice to view and is more difficult to edit, but a browser as MSIE will not noticeable render slower.

At serverside, there are some bigger things that could increasing loadingtime.
As example:
- connecting to a database is a time consuming proces.
- fetching records from a table
- wrong written queries
- not closing and clearing objects
- unwanted queries to the database
- the constructed framework/parser
- including not needed code/libraries/functions


Regards

[Rayr]

Re: Hand coding

Speculating on this subject of hand coding, I wonder if any of the following increase performance short of actually hand coding from scratch:

1) Develop the component as normal, then strip out any unused xbasic? By unused I mean anything that sets a value that the Alpha interpreter would consider default; or remove the many left over references that tend to build up as one switches from one setting to another (e.g. "DropdownBox.Choices =" still exists if you change the field from choice to textbox).

2) Running something like TidyHTML that is supposed to clean up html, removing redundant tags, etc.

3) Selective modification of the A5W page code such as removing a runtime call to the A5W interpreter and replacing with a block of code (ala design time versus runtime HTML).

4) Selectively remove (simple Delete keystroke) sections of the component that appear on the A5W page when the component is inserted (Echo, Update Errors, Search, Data, Details).

My uninformed question is, "what one or two things can I do to get X% greater speed". If I could make the same repetitive change to all of my pages, and that gained me 20%, I'd spend the time, develop a protocol.

Hi Steve,
Where do I get TidyHTML? ever link I find has very old ver from 2003

[Steve Wood]

Re: Speed of a5w pages?

Your guess... Maybe that's the latest. I've only used it once a long time ago.

[Cheryl Lemire]

Re: Speed of a5w pages?

Back in the day when all I did was design web pages hand coding in notepad, I used to use:

http://www2.imagiware.com/RxHTML/