19761 2012-10-29 19:39:40 +0000 Dictionary type for MIDIMessage is likely a performance issue 2012-11-19 16:03:28 +0000 1 1 1 Unclassified AudioWG MIDI API unspecified All All CLOSED FIXED P2 normal TBD 1 cwilso cwilso jussi.kalliokoski olivier.thereaux public-audio oldest_to_newest 77318 0 cwilso 2012-10-29 19:39:40 +0000 MIDIMessage is currently defined as a dictionary. In the case of thousands of MIDIMessages being pumped through the system, that would be less efficient than a type that can be explicitly typecast. 77482 1 jussi.kalliokoski 2012-10-31 01:04:45 +0000 (In reply to comment #0) > MIDIMessage is currently defined as a dictionary. In the case of thousands > of MIDIMessages being pumped through the system, that would be less > efficient than a type that can be explicitly typecast. I'm not sure what you mean by a type that can be explicitly typecast, could you clarify? Do you mean using a constructed type instead, like `new MIDIMessage(data, timestamp)`? 77533 2 cwilso 2012-10-31 18:19:41 +0000 (In reply to comment #1) > I'm not sure what you mean by a type that can be explicitly typecast, could > you clarify? Do you mean using a constructed type instead, like `new > MIDIMessage(data, timestamp)`? In essence, except the other way around. A Dictionary type just means an Object with those members; unfortunately, they can be organized in any way, and the members need to be "searched" for; these types cannot be optimized down to essentially a struct behind the scenes. I received feedback that it is best to avoid Dictionary types for basic structures unless absolutely necessary. 77644 3 jussi.kalliokoski 2012-11-01 09:37:41 +0000 (In reply to comment #2) > (In reply to comment #1) > > I'm not sure what you mean by a type that can be explicitly typecast, could > > you clarify? Do you mean using a constructed type instead, like `new > > MIDIMessage(data, timestamp)`? > > In essence, except the other way around. A Dictionary type just means an > Object with those members; unfortunately, they can be organized in any way, > and the members need to be "searched" for; these types cannot be optimized > down to essentially a struct behind the scenes. I received feedback that it > is best to avoid Dictionary types for basic structures unless absolutely > necessary. True. Since we've already simplified the MIDIMessage interface to just contain the data and the timestamp, we might take it a step further, i.e. change the `send(MIDIMessage)` signature to be `send(Uint8Array data, DOMHighResTimeStamp? timestamp)`, and change the MIDIMessage from a dictionary to an interface (since dictionary makes no sense if it's not ever created by the user). Thoughts? 77674 4 cwilso 2012-11-01 15:32:34 +0000 That's pretty much the conclusion I'd reached as the solution for https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764 - i.e. as the consolidation of send() and sendMIDIMessage(). I'll edit it later today. 77728 5 cwilso 2012-11-01 23:58:10 +0000 Moved to interface (although the difference is irrelevant, now, since MIDIMessage objects are only created inside the implementation, not by developers. https://dvcs.w3.org/hg/audio/rev/f939eca58e74 78472 6 olivier.thereaux 2012-11-19 16:03:28 +0000 No objection in 2 weeks since resolution. Closing.