I later need splice to arbitrarily remove items out of the array
Hm. Three thoughts:
- Do it (that expensive clumsy copy-splice-copy operation) only when you need to.. Not when you only need to push/pop/shift/unshift.
- Copying a whole shared array to a non-shared array and then back again just so you can use splice is ... not good design.
- Removing elements from the middle of a structure called: @jobstack smacks of bad design or bad nomenclature.
I rarely ever find myself needing to use splice. When I do find myself reaching for it, I always pause and look again at my design. 8 times out of 10 I find a better way.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
Ok, thanks for the advice on splice, didn't know it was that expensive.
On the other hand the routine is rarely called and I have no control over what users submit / priority some jobs have ( the files itself contain that info ),
and so the parser decides what file gets processed / computed
( these are long running job descriptions > +1 hour / job / CPU / compute node)
I just mean to say that this snippet will only process a couple of files / hour ( not thousands / minute )
I tested the Thread::Queue module and I'll keep it in mind as future reference, as I don't see a real use for it right now in the current code, (both the main / thread needs access to the same array > preventing jobs from getting processed multiple times )
| [reply] |