rather than 
performance). But you ought to profile first to see if that’s really a time sink. DE Performance can be an issue with large, long-running systems. Below we discuss a few potential solutions.
The calendar queue scheduler is not always the one to use. It works well as long as the ”density” of events in simulated time is fairly uniform. But if events are very irregularly spaced, you may get better performance with the simpler scheduler, because it makes no assumptions about timestamp values. For example, it has been reported that the CQ scheduler did not behave well in a simulation that had a few events at time zero and then the bulk of the events between times 800000000 and 810000000 – most of the events ended up in a single CQ ”bucket”, so that performance was worse than the simple scheduler.
It also has been pointed out that both the CQ and simple schedulers ultimately depend on simple linear lists of events. If your application usually has large numbers of events pending, it might be worth trying to replace these lists with genuine priority queues (i.e., heaps, with rather than performance). But you ought to profile first to see if that’s really a time sink.
Another thing to keep in mind, the overhead for selecting a next event and firing a primitive is fairly large compared to other domains such as SDF. It helps if your primitives do a reasonable amount of useful work per firing; that is, DE encourages ”heavyweight” primitives. One way to get around this is to put purely computational subsystems inside SDF wormholes. As discussed previously, an SDF-in-DE wormhole acts as a zero-delay primitive.
One way to gain a slight amount of speed is to avoid the GUI interface entirely by using PTcl, which does not have Tk primitives.