[racket] case form implemented with a hash

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: users-bounces at racket-lang.org [mailto:users-bounces at racket-lang.org]
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:neil at neilvandyke.org] 
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/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20110929/f905608b/attachment.html>