10-23-2003, 09:21 PM
My website calculates nutrition info from lists of foods. The selected list is loaded from a .js file to create a long drop down menu from which the user can select a particular food.
Originally there was only one list, but as it grew over 50kb I started to get complaints that loading it was hanging up my users' PCs. Not the newer, faster ones with high-speed interfaces. But the older, slower ones with dial-up connections.
So I split the list up. Now it defaults to a Partial List, and you can then select Fruits or Meats or Veggies to get the rest. Or if you have a fast PC, you can select the Complete List which combines them all. It works fine but all seems very unprofessional. I've never seen another websites that gives you options based on the speed of your PC.
It just occurred to me that while they may load slowly, I've never heard of "slow" PCs hanging up loading large .jpg files. I send them to people with "slow" PCs all the time and they are over 175kb.
So could I be doing something with my JS coding that is causing these files to load slowly? Or do graphics files simply load faster?
My .js files look like this:
c=o+'"55.1,.3,.2,14.6,2.5,1.1:3.7 oz=106 g with skin">Apple - small';
c+=o+'"71.8,.4,.2,19.1,3.3,1.4:4.9 oz=138 g with skin">Apple - medium';
c+=o+'"110.2,.6,.4,29.3,5.1,2.1:7.5 oz=212 g with skin">Apple - large';
I have a second question.
I used the code above with "o" in each line instead of "<option value=" to reduce the file size. It works, but does it really help? As the data is loaded into a PC's memory each "o" is replaced with the full text so I suppose it doesn't really help. And could this process slow things down?
Thanks for any ideas, Peter
10-23-2003, 10:25 PM
I did a similar thing and created a preloader, which in fact makes the process slower but it gives something back to the user.
Click on this link (http://www.falecomfleischmann.com.br/culinaria/default.asp?page=netcooking/netcooking.asp), and then on "Tabela de Ingredientes". You need to login so use email@example.com / demo11 .
IE only, probably...
10-24-2003, 05:04 PM
One thing I've noticed with IE is that string concatenation is pretty slow, relative to other browsers. Try this on IE and some other browser to compare:
var s = "";
for (var i = 0; i < 100000; i++)
s += "a";
So I don't think it's the loading of the js file that's taking so long, it's the execution. Also, images and external scripts get loaded in the background so they don't affect the browser UI. But when you execute script code the browser can hang because it can't process window events until the code finishes.
Rather than building a string of HTML you might try writing it out line by line:
document.writeln(o+'"55.1,.3,.2,14.6,2.5,1.1:3.7 oz=106 g with skin">Apple - small');
10-24-2003, 06:21 PM
Thanks for both of your replies. I'll be thinking this over.
BrainJar, as I say I'll think about it but I may not be able to do the document.writeln. I conditionally load different food lists and then put them on the page as needed each time I redraw the page...with each calculation of the food caculator. So I need to have them in memory (in the form of a variable) and not always write them.
Here's one solution to your suggestion of not building a string; start with one long string in the first place:
string='<option value="55.1,.3,.2,14.6,2.5,1.1:3.7 oz=106 g with skin">Apple - small<option value=71.8,.4,.2,19.1,3.3,1.4:4.9 oz=138 g with skin">Apple - medium<option value="110.2,.6,.4,29.3,5.1,2.1:7.5 oz=212 g with skin">Apple - large';
I think that would accomplish what you're suggesting. The only problem, obviously, is that it would be ugly to edit with hundreds of entries in one line in a text editor.
If it could be in HTML I could just insert line breaks which would be ignored. But it has to be in an external .js file which means it has to be in JS.
Is there any way to make it look more presentable in JS?
If not, I suppose I could maintain the data as in my original post, then create a second version for actual use by doing a Find and Replace to re-create the data as above. A bother, but worth a try if no one posts any better ideas.
10-25-2003, 04:46 PM
I tried your little Starting...Done timing test. With Internet Explorer (IE) it seemed to run forever unless I took out a zero in which case it took 3 seconds. With Netscape (N) it took 6 seconds with all the zeros.
I did another test by eliminating all the concatenation. Since I get complaints with .js food lists over 50kb, I created one with 2101 food items over 200kb in size for the test. I actually created two, both with 2101 food items.
The first was with all the items in one line to eliminate any concatenation. It is 206kb.
The second was as before with each item on a separate line and requiring concatenation. Because each line had to begin with c+=' and end with '; and a line ending, the same data took 222kb.
I was thrilled with the initial results running with IE. The new method took only 7 seconds, while the old method with concatenation took 28.
Next I made a third file with only one food item to see what the overhead was. It took 5 seconds, so subtracting overhead (mostly the time required to create the page image) the difference was 2 vs. 23 seconds. A big difference!
As an aside, I also realized that in the coding for the page itself I have about 800 lines broken into small pieces so as to be easily edited. For example:
c+="data for table cell";
By combining lines like these I could probably also lower the 5 seconds I call overhead.
All was good till I tried the same tests with Netscape. There the results were just the opposite.
The new method with all the food items in one line and requiring no concatenation actually took a little longer. Since it wasn't that much longer (18 vs. 14 seconds) and the file size was greatly exaggerated and not that many people use N (though I don't like making things worse for them), I think I'll proceed with the new method. However, I can't understand how it could possible take N LONGER to read the file NOT requiring concatenation. It's even 16kb smaller!?!
Any ideas about this last point would be appreciated. But whatever, I'm very grateful to have learned that I can speed things up by eliminating concatenation.
Thanks again, Peter
10-25-2003, 07:37 PM
You could try building your lists using user-defined Objects instead. An example object might look like this:
function ListItem(type, text, value)
this.type = type;
this.text = text;
this.value = value;
Then you can build an array of all items like this:
var list = new Array();
list = new ListItem("Fruit", "Apple - small'", "55.1,.3,.2,14.6,2.5,1.1:3.7 oz=106 g with skin");
list = new ListItem(...);
To change the drop-down options, do something like this:
selectEl = document.getElementById("mySelectId");
// Remove all options.
while (selectEl.options.length > 0)
// Add an option for each list item that matches the specified type.
for (i = 0; i < list.length; i++)
if (type == "ALL" or list[i].type == type)
optionEl = document.createElement("OPTION");
optionEl.value = list[i].value;
optionEl.text = list[i]text;
if (selectEl.options.add != null)
selectEl.options.add(optionEl); // IE way.
selectEl.add(optionEl, null); // W3C DOM way.
// Initialize the selection to none.
selectEl.selectedIndex = -1;
This way, you build the list just once and basically filter it by type to create the options.