I should add that my timing was on an overall program, not the binary-case alone. I am more interested in the performance of whole programs than in parts that may not significantly add to the time. Jos
_____ From: [email protected] [mailto:[email protected]] On Behalf Of Jos Koot Sent: jueves, 29 de septiembre de 2011 19:55 To: 'Neil Van Dyke' Cc: 'Matthew Flatt'; 'Racket-users' Subject: Re: [racket] case form implemented with a hash A vector with closures is (in my case) hardly faster than a normal case form without closures. See my other post on using a binary search without closures. In my case a gain of 10% only. Jos _____ From: Neil Van Dyke [mailto:[email protected]] Sent: jueves, 29 de septiembre de 2011 17:10 To: Jos Koot Cc: 'Matthew Flatt'; 'Racket-users' Subject: Re: [racket] case form implemented with a hash At Thu, 29 Sep 2011 12:25:16 +0200, "Jos Koot" wrote: > In my case I have a case form which dispatches on a character, 86 different > ones. Therefore I can dispatch by means of a vector. However, almost every > character has its own clause and therefore dispatching on the index of the > character would give no speed up. Do I understand correctly that this jump-table-like vector-of-closures is not fast enough? If this were assembler for a conventional architecture, and you were doing a DFA-like lexer, I'd think that a jump table would be quite fast (but with some bloated constant for code size). I wonder whether there's an optimization the compiler/JIT can make that would be a big help, perhaps with additional hints from the Racket code? And if so, would that optimization likely be useful for anything other than optimizing "case" of characters? -- http://www.neilvandyke.org/
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/users
