The Web Control framework has lots of overhead and it will be way slower than pure Process class generated HTML output even in production mode and the slower the machine the bigger the difference between the two will seem.

Ajax callbacks can be optimized by using process methods rather than page methods in a Page class. If you have an external Process class the performance will be typical process class performance and bypass a lot of the overhead in the page framework... Look in the documentation for more information on how to set up external Process Class Handlers.

+++ Rick ---

After poking around a bit today, I'm not sure where the best place to handle a hit that is not married to a _page.wcsx should go.

I would like to continue to enforce my OnProcessInit security trapping and it seems like, I should be able to hook into firing a routine by testing if it is InList() or something and then avoiding calling on the page as you suggested.

Now are you going to tell me to look at the documentation -- I have...<g>

--hm

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?

Any thoughts are welcome.

--hm