Use scala.collection.immutable.Queue for FIFOQueue instead of List

[okumin]

scala.collection.immutable.List is a singly linked list, so it is not efficient(O(n)) to append elements.
Using scala.collection.immutable.Queue, enqueue will be faster.

[okumin]

This FIFOQueue requires O(n) time for contains, deleteById and deleteByGroup.
If these operations is called many times, another data structure should be chosen (e.g. use two LinkedHashMaps whose keys are Task ID and group).

[buster84]

Thank you for your contribution!!!!
deleteById and deleteByGroup are not called many times but it depends on applications. contains is called as many times as enqueue so we need another data structure as you mentioned. Could you fix it?
BTW, this link is very useful: http://docs.scala-lang.org/overviews/collections/performance-characteristics.html

[okumin]

Thanks to your response.
There is a thing that I want to confirm.
CustomQueue seems not to be assigined tasks that have the same id, and then I can work on condition that this is constraint on CustomQueue, right?

[buster84]

Now, there is the constraint on any CustomQueue. But I am considering that the constraint should be depends on applications. So I am going to add CustomQueue trait isAddable method which check whether given task can be enqueued or not.

And I think FIFOQueue should have the constraint because it may be used as exclusive control in most cases, and actually we are using the constraint as exclusive control.

[buster84]

I forgot to say.. It is a good question!!

[okumin]

Updated branch.

But I am considering that the constraint should be depends on applications.

I agree this point, so I didn't change any interfaces and improve perfomance only.

[buster84]

Thanks!!