Back To Start Of Archive
Taken From The Forum: Archived Topics for the old Version 3.0 JavaScript Menu
Forum Topic: Click to view post
Last Updated: Saturday July 14 2012 - 06:07:31
Menu Speed or Caching Generated DHTML
Poster: carcus88
Dated: Wednesday May 7 2003 - 17:17:59 BST
Hi I have a very large menu that will be growing even larger for some of our big clients. The problem I have is speed. It takes over a minute on some computers to render the page. This is a client using a 1 GHZ PIII processor.
What can be done if anything to speed up the menu? Is it possible to generate the DHTML menu and store it in a static page?
You can see my test page here
http://testwiis.icnfull.com/online/test.html
The menu file is here
http://testwiis.icnfull.com/online/menu ... u_array.js
The menu_array.js file is generated from a database when the database changes. Like I said before this is a small client. I don't even want to think about how long our largest clients (with over 60 publications) wait time will be.
Thanks for any tips.
Poster: John
Dated: Wednesday May 7 2003 - 23:16:32 BST
Obviously you've got a devil of an array file there. 1400 lines is just a tad on the heavy side
The only thing I can think of is give v4 a try. It's still in beta, but extremely stable, not to mention faster. The downside is you'll have to rewrite the array (the converter's not ready). Trim your array and see if you notice any difference before taking the full plunge.
See http://www.milonic.com/4beta/menu.htm.
Poster: carcus88
Dated: Thursday May 8 2003 - 13:22:26 BST
jgillett wrote:
Obviously you've got a devil of an array file there. 1400 lines is just a tad on the heavy side
Your not kidding. You dont even want to see the menu size for our largest client!
I'm gonna give version 4 a try and see what happens.
I started hacking into the version 3 code last night and managed to extract the DHTML code it puts out. My idea was to extract the DHTML submit that to a PHP page and store the DHTML in a session variable so I can just dump it out and only have to generate the menu once. It's almost there but if Version 4 works forget about that.
Poster: John
Dated: Thursday May 8 2003 - 15:36:23 BST
Keep us posted here. V4 is a ground-up rewrite, and Andy will be interested in your results.
Poster: Andy
Dated: Thursday May 8 2003 - 19:48:57 BST
Yeah it would be interesting to hear your views on how things go with v4.
I've recently had talks with a well known electrical retailer in the US and they have a large menu that with v3 wasn't too great. V4 was at least twice as fast even with the bells and whistles.
I think if we develop a lite version based on the same data structure we could get the menu runnning at light speed.
Early tests proved some 8 to 10 times faster than v3 but as we began to add all the code for images etc it kinda slowed things down.
I think a lite version is the way forward, it kinda gives you a choice but there will be a limitation on what the lite version will do. What do you think?
-- Andy
Poster: John
Dated: Thursday May 8 2003 - 21:48:32 BST
Andy wrote:
I think a lite version is the way forward, it kinda gives you a choice but there will be a limitation on what the lite version will do. What do you think?
I think a lite version sounds great I'd be willing to bet there are a lot of folks who don't/can't use anywhere near all the goodies you've managed to cram into V4 (including me - my stuff is pretty simple) who would jump at a lite version.
Another winner in the making...
Poster: carcus88
Dated: Thursday May 8 2003 - 22:30:22 BST
Hooray for a lite version!
Is it done yet? :mrgreen:
Ok I've converted to Version 4 and I must say Andy I'm impressed.
The page loads much faster but still not nearly fast enough. When you position over a large menu there is a delay that was not there before. I lowered the _menuOpenDelay option but that didn't help, looking at the processor usage I'd say its definatly script processing. The scrolling option kicks butt, I mannaged to do away with my "MORE..." submenus and replace it with the scrolling menus. The scrollers work great on the first level but seem to degrade on submenus. Take a look at the Basic->Country menu.
Also third level sub menus are not displaying all the options for some reason. Look under Publications->Java Devlopers Journal->JDJ-Language-Used. There should be a multitude of languages besides Visual Basic.
Overall I'd say version 4 is a winner. It just needs some speed inprovements. The scrolling option is going to make all the differance in the world when it works correctly. Keep up the good work.
I'm still interested in trying to cache the DHTML code though. No matter how fast Andy makes the menu it will utimatly depend on the clients PC which in my case will be anywhere from a PII to a P4 . My smaller slower clients will not like the wait time the have to go through every time they build a qurey.
Is it possilble to get a version of the source that hasn't been squeeeeeezed into on line so I can toy with it Andy?
You can check out my latest overly large menu here
http://testwiis.icnfull.com/online/test.html
Poster: John
Dated: Thursday May 8 2003 - 22:55:46 BST
I get a 404 when hitting the URL you just posted...
COBOL, eh? I can do the same thing in RPG with 75 fewer cards...
Poster: carcus88
Dated: Friday May 9 2003 - 1:16:38 BST
jgillett wrote:
I get a 404 when hitting the URL you just posted...
Strange it works fine for me from work and from home. You obviously must be getting to the server if you get a 404 so its not a DNS problem. It's definatly
http://testwiis.icnfull.com/online/test.html