The queue is big and slow

[MfHYoJEcYf50]

With 150 entries, it takes 8 seconds to draw the table, because due to the design choice of giving the user the opportunity to move an entry to position X, and with having all options for entries filled in, 150 * 150 entries becomes 3 MiB.

Without all the options, it's 150 KiB and takes 0.5 seconds to draw.

I was just wondering if you had any plans to change this in 0.5?
For example by either ditching the whole "Move to position X", or at least by not prefilling the choices for positions to move to, but instead using onclick to populate the select-options.

It just seems strange to me this particular choice is there, as I think it would be better if we could simply move to top / bottom, one up / down, or reprioritize.

Your thoughts?

[switch]

0.5 has support for gzip compression, which should give you faster page loads.

The SMPL and Plush skin will use pagination to limit the amount of items shown to reduce on this behaviour.

As for the Default template, I am not sure if that will be upgraded to support pagination.

[MfHYoJEcYf50]

0.5 has support for gzip compression, which should give you faster page loads.

How would zipping each page, on localhost, make the browser's generation of the DOM any faster?

I start to receive the page after 70 milliseconds, and the browser finishes rendering it after ~ 5 seconds.

Wouldn't gzipping the page before sending it, only add to that time?

The SMPL and Plush skin will use pagination to limit the amount of items shown to reduce on this behaviour.

That's good, which for a page of 50 elements would reduce the time to a few seconds.

As for the Default template, I am not sure if that will be upgraded to support pagination.

What about not expanding the options for "move to position X", but instead use "move one up / down", and "move to top / bottom"?

That could conceivably make the page load 16 times faster, could it not?

[switch]

The page renders while it downloads. It is not a dom generation that is slow, it is the insane amount of html that is transmitted for the dropdown menus producing large file sizes.

I am not a fan of "Move Up" / "Move to the top" positioning as it removes the finer precision that is currently there on large queues. It is a hard one to get right really.

[MfHYoJEcYf50]

I am not a fan of "Move Up" / "Move to the top" positioning as it removes the finer precision that is currently there on large queues. It is a hard one to get right really.

Okay.
But then, may I suggest not actually filling the options for the drop-down boxes, before they are actually clicked?

It (might) be easily done, by just having an array containing the options.

EDIT: Also, I don't care about "finer precision". When I want to prioritize something for download, I don't want a dropdown-box offering 1 million positions. I want to put stuff at the top / bottom.

[shypike]

May we should drop the file listing expansion altogether?
When you click on the job name you get a page containing the files.

I mean, anyone with a really big queue isn't going to look at the progress of individual files.