Re: extending a select list

RobG wrote:
Ian Richardson wrote:
RobG wrote:
Ian Richardson wrote:
[...]
...because when adding options to a select element using the DOM, Opera
is _blindingly_ fast... The application I'm developing could have
hundreds or thousands of options needing to be added.

That sounds disasterous - thousands of options? Oh well...

The application allows for setting of the start of an event, either by an explicit date or an offset. Changing any aspect of one keeps everything together. If the date is changed such that one of the offset menus needs to explode in size, the user is warned of this and given the option to roll back the change if necessary.

However, there are certain date restrictions I perhaps should impose, like maybe limiting the maximum date to 100 or 150 years in the future.

<snip>

1. The list may not have a first value (and its text), at any
pre-determined value, so it's easier to read the final value.

An empty select is invalid HTML, you may have issues on that front -
should a browser render a select that has no options? As far as I
know, they all do. But who's to say they all will, and if they don't
they aren't (strictly) at fault - or are they? What sense will a user
make of a select with no options?

1. Did I say at any point that I'd have a select list with no options? No I didn't.

2. I didn't bother to check previously, but now I know why a select list with no options has a dummy entry added by some browsers!


2. I know Javascript will type convert all over the place. I choose not
to be equally sloppy.

How? There is no type conversion, the length property is defined in
the specification as being a number. Converting it from a primitive to
a Number object is simply unnecessary. I suspect that it's slower than
implicit conversion anyway, but in either case the time taken is
infintesimally small and utterly insignificant - it only happens once
per call to the function.

In the example I initially provided, it just so happened that the list started from 1 and each entry had the text and value one higher than the one before... so in that special case, the numeric value of the last option was the same as the numeric length.

The length (i.e. number of options) is a number, yet the values of any attributes are of type string. To be safe when using this string in any numeric calculations, I'd convert to a number. I've had these sort of type-related problems before and I'm not going to change my defensive coding based on your comments.

var maxV = replacement.options.length - 1;

You don't need to do that, nor do you want to subtract one from the
length. You want the number of options equal to extent, don't you?.
Not always.

If the list starts at 17 and I was the final entry to be 23...

Then you just want to add options 18 to 23 inclusive - anyhow, I'll
leave that logic to you. I think you've left out too much for me to
know what you are doing here.

Now you're just giving up. I'll explain for you again:

1. Assumption: the list (both the text and value) are integers.

2. Assumption: the numeric gap between each option in the list is 1.

3. Lists can start at any value.

4. For some reason (see above), there is a requirement to add further options to the end of the list.

5. Adding options should be done in the fastest manner possible, not only to reduce the time the user is held up, but also because there may be a large number of options to add.

6. Adding options in a manner which doesn't halt user interaction causes problems in the browser when the user attempts to interact with the select list being extended.


Mind you, I thought the idea of providing an explanation (as I did, albeit nothing like as verbose as this one), together with example code illustrating what I was trying to do was for people to assist me rather than attempt to criticise at every opportunity or think I want them to write it from scratch. I've read enough postings from people who have not even bothered to show code as evidence they've tried, and the terse responses.

So much for co-operation.

<snip>

1. I will not have multiple exits from a function.

Then use if - which provides exactly the same functionality as a switch
with only one condition (unless I'm missing something).

....which you are. if() may be easier to code, but switch is faster. I'd previously made this claim.

<snip>

As will an if, while or do. I think in absolute terms, any of them
will be faster than switch - but we're talking nano seconds here. See
how many loops you need to do with a test harness to get meainingful
timed results.

The main killers of my application at the moment are:

1. Some unbelievably long string handling.
2. Extending options.

I've recently discovered that long string handling is a bad bad thing, and I'll be looking at using a big array of short(ish) strings and a join().

I was looking at extending options as I had originally described as both an exercise in programming, and as trying to find out if it would give me any speed advantage.

The short answer is it appears to be up to 10% slower than the DOM 0 method in IE and Firefox, but it's around 30 times quicker in Opera!

<snip>

Ah, so what you really want is a faster method than new Option()? I'm
not sure there is one specific method that is faster in all browsers.
You can't use createElement in IE, you don't want to use new Option()
because Opera is too slow and if you use innerHTML I'll bet some other
browser drags the chain. Test it and see.

I wasn't necessarily looking for or expecting to find one method that's faster for all browsers, but being able to optimise this area for one browser is a good thing.

Incidentally, if you decide to do that, don't use the += operator to
concatenate strings in IE, it is very slow (when used thousands of
times in a loop). Better to put the option HTML strings in an array
and use join().

I wasn't doing that but, as I've mentioned above, I will be looking at join() for some other string handling.

<snip>

As you can probably gather, I've now found a solution that works (and only two lines needed changing from my original posting). It's only a (huge) speed improvement for Opera (and for IE it gets exponentially slower - I may look at extending a chunk at a time), but it proves the point to me.

Ian
.

Relevant Pages

  • Re: PMJ The REALLY final card list (nearly!)
    ... > That's my Firefox browser. ... from your Firefox Browser & that was Served up as a "304 Not Modified" ... something strange is happening to the string lengths in the string ...
    (uk.people.silversurfers)
  • Re: My linked list
    ... the string allocation failed. ... sharing of string between lists, but you don't seem to be going that ...
    (comp.lang.c)
  • Re: Semantics of ==
    ... >> No they aren't, since l's first element is a list, not a string or ... > well-founded list be a string or number. ... lists that can be well-founded are strings and numbers. ...
    (comp.lang.python)
  • Re: Efficient way to break up a list into two pieces
    ... x = SomeReallyBigListOrString ... has to copy the entire list or string. ... Could lists gain an .itemsmethod with start and end positions? ...
    (comp.lang.python)
  • Re: Efficient way to break up a list into two pieces
    ... x = SomeReallyBigListOrString ... has to copy the entire list or string. ... Could lists gain an .itemsmethod with start and end positions? ...
    (comp.lang.python)