I would have tried a different compression, however, this one may work better as long as the list is all ways alphabetical.
If we want to use binary searching, the list should be alphabetical. I see no problem with that: the list is auto-generated, so why not sort it first?
To optimize the list further, I would pick several hex characters, preferably in a row that will not occur in a function name. We use these instead of the 123 characters because we can add a default of no value. We would have to pick what the best default value was. It will probably end up being the value that was before it. This would effectively reduce some space and would also make it near to imposable for someone to edit the file in a text editor. This means the file will have to be created by a bot.
I don't really understand what you are saying here. Could you give an example of this type of compression, or some pointers to more information about it?
I only used this 'prefix compression' because I knew it, and it is easy to decompress in JavaScript. It is also quite effective with this list (lots of common prefixes).
The second idea that I think may be good was discussed a little earlier. Break the string up into a single string per letter.
Do you mean "break the array up into a single array per letter"?
After the user types the first letter of the search word, the drop down list would download and appear. Lets think about how may users are going to type e.. c.. h.o and wait for all the words to come up? Most (I think) would type something like ech..o after they see that the last letter is in fact o. This should give us a little time to load a little file. In my case, I would rather wait a bit for a small file to load rather then go to a search not found page. But I would also rather not wait for a file to load(even if it did load at the begining) if I know what I wanted (and I normally do.) Is anyone following my argument? Fast first page. If you know what you want, don't wait for small file (if you can beat it) and if you don't know what you want, wait a sec.
Dynamically loading files using JavaScript is not so easy. I really think loading the full file at once is the best way to go. If the file hasn't loaded yet, you can use the search box like it works now: enter a function name, and press enter to go to the correct manual page.
Only if the file has loaded, a list appears when you enter values. If you enter an existing function name, the script will recognise this, and send you directly to the correct manual page.
So it is only an addition, which doesn't make the loading of the main page any slower, just like loading an image doesn't prevent you from reading the text on the same page.
If we offer the user a direct search function, it should work instantly. That means either it doesn't give any results (if the JS file hasn't loaded yet), or it gives results as you type. You don't have time to wait for an additional file to load.
Greetings,
Jan Fabry
