Ordered queue handling by workers

[jrochkind]

Just an experiment, to have some concrete code to talk about, and to give me an exersize.

See: #624

Although I'm interested in it, I also understand if you ultimately think this feature is not necessary and would like to avoid it bloating the codebase. Abstractly, you can do the same thing with priorities, although it can be less convenient to do so (in some cases extremely cumbersome), and priorities don't allow you to re-shuffle how an existing queue of jobs is handled like ordered queue workers do.

I updated the benchmarking with more clear combinations of different sorting. Using the ordered queue feature does have some slowdown; I suspect it won't matter for good_job-scale loads, and also any performance hit from this feature will only be if you use the feature, it shouldn't effect you if you don't.

If I run the benchmark multiple times, sometimes I get some differences between examples that other times same-ish for. Here are two examples.

Comparison:
sort by priority only:      337.0 i/s
       without sorts:      327.9 i/s - same-ish: difference falls within error
sort by creation only:      312.0 i/s - same-ish: difference falls within error
sort by priority and creation:      303.1 i/s - same-ish: difference falls within error
sort by ordered queues and creation:      269.9 i/s - same-ish: difference falls within error
sort by ordered queues only:      268.1 i/s - same-ish: difference falls within error
sort by ordered queues, priority, and creation:      209.1 i/s - 1.61x  (± 0.00) slower

Comparison:
sort by creation only:      386.7 i/s
sort by priority only:      364.7 i/s - same-ish: difference falls within error
       without sorts:      352.3 i/s - same-ish: difference falls within error
sort by priority and creation:      293.8 i/s - same-ish: difference falls within error
sort by ordered queues only:      284.3 i/s - 1.36x  (± 0.00) slower
sort by ordered queues and creation:      276.8 i/s - 1.40x  (± 0.00) slower
sort by ordered queues, priority, and creation:      226.2 i/s - 1.71x  (± 0.00) slower

[bensheldon]

I think this looks great. I'm curious what happens with some random strings like +*, but I'm happy with this. 👍🏻

I made a few suggestions/fixed-typos in the docs. I'll merge those and release this.

[bensheldon]

Thank you! Released in v3.2.0

[jrochkind]

Thanks @bensheldon! And thanks for the doc clarifications.

I suppose +* would end up telling the pool only to pull from the queue named "*". Which, if you don't have such a queue name (and it would be strongly discouraged for you to!), will end up pulling no jobs. 🤷

Compare to if you specified -* as a queue. (I guess that would end up being the same as just *, so long as you have no queue named *!). + is being handled exactly like -, as far as parsing.

[bensheldon]

@jrochkind agreed. I think we can ignore the edgecase semantics until someone notices 😄