Grids are very useful, but why so slow (relatively) ....

[drgarytraub]

This is not a complaint, but rather an observation, and meant to encourage some ideas.

We all know that grids are very useful, and easy to implement. If you want a table of data, you point and click to select fields, various options, and oila, you have a nicely formatted table of data on your page. But they can be slow, particularly as you add rows or columns, and particularly if you make them editable.

As Steve Wood has mentioned, I (and others) have noticed tremendous speed improvements by using Xbasic to generate the grid from scratch, using just Xbasic and html. I can take a grid that takes 8, 9, 10, or more seconds to load, and get it to display in less than a second with hand coding. Using html you can make the hand coded grid look just like the alpha grid, including colors, alternate row shading, etc. I have even found a way to add column sorting to the xbasic generated grid, without much trouble.

So, it got me thinking: Why does the alpha grid take so long to load (relatively)? Surely, there must be bunches of code that is slowing it down this much. Is it the error checking that is needed if the grid is editable? Or something else?

In any event, I have a thought/suggestion (maybe this should go in the suggestion area, but I am really looking for ideas). Can a basic grid (display only - no editing on the grid) be an option? This would be for display only, would include column sorting, and allowing links to other pages for data editing. Does this option already exist?

Or, if not, perhaps we, on the forum, can begin to collaborate on an xbasic/html grid such as the one I have described. Like we did with the monthly calendar. I am sure, with input from some of us, we can get a very nice, very fast xbasic/html grid.

Anyone interested in this?

Gary

[rleunis]

Re: Grids are very useful, but why so slow (relatively) ....

I would be interested to know what Alpha has to say about this.
If it is the case that the standard grids are much slower, than Alpha should be able to explain why there is so much more overhead in standard grids than ones which you can develop using xbasic.

One of the big plus things for me regarding the Alpha product is that you do not have to program so much by using standard grids...If you would have to program anyway, then I would start to learn a more OPEN SOURCE language instead of the proprietary XBASIC language of Alpha.
I have seen very fast performing applications using Java over tomcat with hibernate against oracle databases using wicket for user interface.

But that's all a steep learning curve. And alos the speed of the development compared to what you create with standard grid in Alpha is terrible. Alpha has a great front end to create program free code against database. Let's hope they can improve on performance, f.i. by implementing AJAX routines automatically (for dummies) in grids and taking the overhead as much as possible out.
If Alpha can outperform not only in development speed, but also in performance, than they would truly have a very competive product.

regards, Ron

[Steve Workings]

Re: Grids are very useful, but why so slow (relatively) ....

Grids are slow because the code used to create them is huge. If you've looked at other code generated by, say, Action scripting, you see that Alpha Software has gone to great lengths to try to accomodate every possile scenario as they build their genies. And the grid builder is, in effect, a big genie. This is actually one reason Alpha's so good -- they anticipate and handle so many different uses, conditions, etc.

But, of course, that leads to the speed issue we see here.

I don't know if it's worth the time to build a generic replacement, with fewer features and less error handling. Each grid is a bit different.

I'm thinking it might be as/more useful to provide some basic instruction, examples, etc. to show people how easy it is to build your own simple grid, and help people understand how to enhance it with hyperlinks, column sorting, etc.

In effect, let's teach people how to build their own, rather than try to build a one-size-fits-all.

I see Ron posted before I got done. AJAX that's already here, and AJAX stuff that's coming, will certainly be a very important contributor to the ball of wax.


Give a man a grid builder, he'll have his data up today. Teach a man to build a grid...

[Bill Parker]

Re: Grids are very useful, but why so slow (relatively) ....

The difference witrh grids vs. action scripting is that action scripts can be converted to xbasic and stripped down to fighting weight. This gives the developer the best of both worlds.

This was originally possible in v6 WAS, but then the xbasic became encapsulated. I can understand if Alpha's concern was that developers would incorrectly edit the code, because it was huge. But that approach might again be a target.

Bill.

[EricN]

Re: Grids are very useful, but why so slow (relatively) ....

I've mentioned the grid issue in my thread, "Need For Speed" http://msgboard.alphasoftware.com/al...ad.php?t=76824

When I first started my app project, I created grids with lots of calc fields not realizing this, complicated filters, etc. slows down the load time. Now that I thought I was finished with my app and tested only to see load times very slow (on VPS) I'm revisiting the ideas of rebuilding many of the grids.

In effect, let's teach people how to build their own, rather than try to build a one-size-fits-all.

I would like to know how to "build" or hard code grids if this does speed up load time.

[jkletrovets]

Re: Grids are very useful, but why so slow (relatively) ....

I would like to know how to "build" or hard code grids if this does speed up load time.

I second this.....I would be up for trying to learn how to do this.

I would be willing to contribute to another group project like we did with the calendar......although since I am pretty new to the web side I am not sure how much I could add to the mix but I am willing to try.

IMHO - it would be cool if there was a no frills "function" that we could use to just pass the table name and fields that we want in the read only grid and have it pump it out so we could easily use these "optimized grids". Not sure if that is possible or not (or how hard that might be).

Dr. Gary - where did you start as far as learning to write your own grids? Is there some place to start in the help file you could point me to?

Regards,

Jeff

[drgarytraub]

Re: Grids are very useful, but why so slow (relatively) ....

Jeff,

It really is not that difficult, but requires some knowledge of both Xbasic and html.

To get a feel for outputting data to a page, start with something simple:

Create a new a5w page. Insert some xbasic something like:

dim tbl as p
tbl=table.open("[pathalias.adb_path]\appointments")
query.filter="date={12-10-2008}"
query.order="Fullname"
query.options=""
tbl.query_create()

while .not. tbl.fetch_eof()
?tbl.time+" "+tbl.fullname+"<br>"
tbl.fetch_next()
end while

tbl.close()

This script will output appointments of 12-10-2008, sorted by fullname, to the screen. Each line will show time and fullname.

The ? causes output to the screen.

This is is a very basic listing.

To format the output so that it lines up into nice columns, with colors, shading, etc, requires knowledge of some basic html, specifically about tables.

The basic format is like this:

<table>

</table>

Those tags define the begimnnign and end of a table.

To define a row in the table we use <tr> and </tr>, and cells within the row are indicated by <td> and </td>.

So, if I rewrote the above code with this html, it colud look something like:

dim tbl as p
tbl=table.open("[pathalias.adb_path]\appointments")
query.filter="date={12-10-2008}"
query.order="Fullname"
query.options=""
tbl.query_create()

?"<table>"
while .not. tbl.fetch_eof()
?"<tr>"
?"<td>"
?tbl.time
?"</td>"
?"<td>"
?tbl.fullname
?"</td>"
?"</tr>"
tbl.fetch_next()
end while
?"</table>"

This now results in a more nicely formatted table, with everuthing in columns. The formatting, colors, width of coumns are all more html, but this might get you started.

Gary

[Pat Bremkamp]

Re: Grids are very useful, but why so slow (relatively) ....

Actually, Selwyn demonstrated this way back in V6, but it took me a couple years to figure out how to use it!

Here's a simple start for those of you wanting to try this. This code creates the html table:

 
'==== get the announcements
dim ta as p
dim qa as p
dim n as n = 0
dim vAnn_html as c = ""
ta = table.open("[PathAlias.ADB_Path]\announce.dbf")
qa = ta.query_create("T","ann_active=.t.","sequence")
n=qa.records_get()
if n=0
 vAnn_html="<h4>There are no active announcements</h4>"
else
 ta.fetch_first()
 while .not.ta.fetch_eof()
  vAnn_html=vAnn_html+"<h4>"+alltrim(ta.Ann_title)+"</h4>"+crlf()+"<p>"+ta.Ann_body+"</p>"
  ta.fetch_next()
 end while
end if
qa.drop()
ta.close()

and this code displays in on the page

 
<div id="rsidebar">
<h3>Announcements</h3>
<%a5 ?vAnn_html %>
</div><!-- end rsidebar -->

and this little piece of the CSS style sheet formats it

 
#rsidebar{
margin-top: 0px;
padding: 10px 10px 0 10px;
float: right;
width: 200px;
}
#rsidebar p{
margin-top: 5px;
}

You can see the result at http://www.asqpdx.com/index.a5w in the right column.

By the way, I use a regular grid to enter this information, but this approach since the output is read only.

Pat

[JerryBrightbill]

Re: Grids are very useful, but why so slow (relatively) ....

There have been a number of posts concerning performance.

Speed Issues of WAS

Speed of a5w pages?

A grid can be relatively fast, depending on design, but if all you need is a view only list with no sorting, no navigation to multiple pages of data, a hand coded list will be faster at runtime. The AJAX grid that is in development will be very close to hand coded speeds when initialized and actually faster in operation as only sections of the grid as refreshed on a request.

The biggest negative factors that creates slow grids and pages are trying to include too much information in a single grid or dialog, using dropdowns in individual reports in a grid, using multiple grids or dialogs on a page, or using complex grid linkers with slow grids. Careful design can make grids significantly faster.

This speed issue exists in any web product. Some time ago, I tested a page built in another well known web design program. It was a grid with 250 lines, about 15 fields per record, each record had 4 dropdowns, and each dropdown (built dynamically) had up to 250 records. The resulting page was huge and took many minutes (not seconds) to load. When the same grid was rebuilt in Alpha, the speed was slightly better, but anything that takes over 5 minutes to build and load is unacceptable to an end user. Just replacing the dropdowns with lookups drastically reducing the page build and construction time.

[jkletrovets]

Re: Grids are very useful, but why so slow (relatively) ....

Thank you Gary and Pat....

That doesn't appear too difficult at all....I want to play around with that now.

Also, thanks for the update and additional information Jerry.

Regards,

Jeff

[EricN]

Re: Grids are very useful, but why so slow (relatively) ....

Hand holding requested...

Attempting to replace a grid with code. I currently have this:
dim tbl as P
dim qry as P
tbl = table.open("[pathalias.adb_path]\posts")
query.filter = "userid=" + quote(vUserid)
query.order = quote(jobtitle)
query.options = ""
qry = tbl.query_create()
tbl.fetch_first()
while .not. tbl.fetch_eof()
? Jobtitle + "-" + JSSiteCity + ", " + JSSiteState + "<BR>"
tbl.fetch_next()
end while
tbl.close()

vUserid is valid and is displayed on page- twang.

The code is currently counting the number of jobs the company has in table and displaying the CURRENT job this number of times. I want to display all the jobs company has submitted.

[Pat Bremkamp]

Re: Grids are very useful, but why so slow (relatively) ....

I think you want

? tbl.Jobtitle + "-" + tbl.JSSiteCity + ", " + tbl.JSSiteState + "<BR>"

Pat

[EricN]

Re: Grids are very useful, but why so slow (relatively) ....

Of course. Should have reviewed Gary's post above more closely. Thanks Pat. That was it!