Re: performance boosting

... it is amazing, how quickly one forgets that methods within the process subclass are valid. I was thinking trying to remember how to do this for at least two hours, I was almost at the point of adding a second script map to get around the issue... oh my, I guess I'm getting really forgetful! <g> (that sucks!!)

--hm

So I added another method to Process to handle the request. It fires after OnProcessInit and seems to respond very quickly.

Yes AJAX callbacks against Process methods are going to be significantly faster than full page requests since those will always construct a full page of controls. All that overhead goes away.

+++ Rick ---

Now on to building the repeater with jQuery...

Thanks

--hm

If you need to offload processing to Ajax you should do that right from the get-go. Don't even use a Repeater to begin with but create what ever the repeater code is on the client side and always load that data via Ajax. You can use the parseTemplate functionality in ww.jquery.js to provide with an easy templating mechanism that's all client side and then use Ajax to load the data and embed it into the page with a few lines of code.

+++ Rick ---

While I'm in development...., I'm seeing 2.5 second hit times on my laptop.

It is not the newest nor the fastest thing under the sun but it not a dinosaur either; 2 Duo 2.4 ghz, 3 gb ram XP class machine.

But as I continue to add functions to this five tab page with several repeaters, modal dialogs and ajax callbacks, I'm really starting to wonder how I'm ever going to get back to sub-second hits.

Working in the WConnect 5.x environment is SO nice but are the features of ease starting to pile up and becoming a trade off for performance.

How much improvement should I expect to see by going to COM and pre-compling the pages?

Can't really comment on COM since almost all our customer sites run under COM so that's the norm for us.

In the early days of 5.0 I put some pages out that were compiled at runtime. Switching to pre-compiled seemed to help - but we didn't do any rigorous timing tests so I can't give you any specific results.

But you can't get around the fact that there's still some overhead involved in having VFP generate all that HTML. My slowest page is a form for international students that involves a number of lengthy drop down menus (selecting from a list of countries, etc.) - it does seem to take awhile to draw those up, even tho the page is pre-compiled. These are based on wwWebDropDownList controls - wonder if it would make a difference to fetch the data with Ajax and have Javascript populate the menus?

One way to make loading really fast is to hard code in VFP the HTML without using WC controls. A dropdown list is a good example, it only takes a few lines of code. But I guess before doing it, I would look at where the time is being spent. Add some "? SECONDS()" along the way through your page generation.

In my case the time was spread out throughout the entire process with no individual control taking a lot more time than any other. I just have a ton of stuff all going on at once.

Thanks for the feedback.

--hm

--stein