I am looking for an efficient data structure, that’ll allow me to cue events … that is, i will be having an app, where at any time in execution, it is possible, that an event will be raised for a future point in execution … something like:
- t=20: in 420 seconds, A occurs
- t=25: in 13 seconds, B occurs
- t=27: in 735 seconds, C occurs
- …
so i’d like to have a data structure, where i can put in any event in any time in the future and where i can get and (by doing so) remove all due events … also, a plus would be, if i were able to remove an event from the datastructure (because it was canceled) … not too important though, since i can simply flag it as cancelled …
my first thought was, maybe to do some sort of tree, but i guess the removing-due-events part requires a lot of rebalancing …
i am considering simply having an int hash, mapping timestamps to either null or stacks of events that are to occur at that point in time … i think in scenarios, with a lot of events (possibly multiple every second – which is what i intend to work with), this actually isn’t such a bad idea after all …
so i am eager to hear your input … 🙂
edit:
- to be more specific: i think n here is at about 100K-1M, and i guess i might be having about 1-100 events/second …
- the t is of no special importance … it is only to illustrate that a future event can be “enqueued” at any time …
thanks
back2dos
If your events have a well defined upper limit (e.g. no events later than 2 days in the future), you can simply have an array indexed by # of seconds from “beginning of time”.
The value of the array is a list of events at that offset.
Listing or Removal is very efficient – simply find the offset for the time where you wish to list or cut off and get or re-initialize the arrays pointed to by indices after that offset.
If your events can stretch out indefinitely into the future, then your own idea of using a hashmap from offsets to list of events is the best one, with a twist – have a sorted list (however you wish to implement it) of known offsets, that way you will have very efficient lookups (e.g. you won’t have to loop over every key ion the map).
You don’t need to delete anything from the list of known offsets so no issues with re-balancing – you merely delete from the arrays that hashmap points to.
Also, it seems unclear from your question whether there’s any need to know “t” – the time when the event was raised. If you need to know it, store it as part of the event. but the reference to when the event should happen should all be absolute in relation to some starting point (if it’s a hashmap with unbounded range, you can use epoch seconds, and if events have bounds like in the first array solution I listed, you should instead use “# of seconds since beginning of range” – e.g. from start of day yesterday.