Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #51383
| From | Bernd Paysan <bernd@net2o.de> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: RfD Recognizer, 3rd version |
| Date | 2016-09-27 13:23 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <nsdrrs$798$1@dont-email.me> (permalink) |
| References | (1 earlier) <a6a3672d-2e36-4085-93bf-fbf4cc3a7d0e@googlegroups.com> <87oa3a6jn2.fsf@jester.gateway.pace.com> <7cf7cab7-4593-48e7-a088-218458d61003@googlegroups.com> <87fuol7ups.fsf@jester.gateway.pace.com> <b9qdnb_VYP2QrXfKnZ2dnUU7-TfNnZ2d@supernews.com> |
Am Tue, 27 Sep 2016 03:38:37 -0500 schrieb Andrew Haley: > I think the proposal is to allow recognizers to be run before dictionary > search. The dictionary search itself can be a recognizer, > and can appear anywhere in the recognizer stack. Yes, of course users can change the default recognizer stack to fit any of their needs, and if they add slow recognizers on the top of the stack, the whole search can become pretty slow. Comparing gforth-0.7.3 vs. current git Gforth on loading cross.fs however shows a measurable difference in favor of gforth-current (32ms vs. 36ms user time). Something else became better... and in fact, we have tuned our hash function. If you think that the simple loop through the recognizer stack is too expensive, it's certainly possible to compile a tuned search function on every SET-RECOGNIZERS (possibly giving it a unique name derived from a hash over the xts, and using that name if it is already available), and that should eliminate the dynamic overhead. But we have that sort of overhead already for the loop through the search order. In fact, treating the search order as recognizer stack and using a similar precompilation scheme on SET-ORDER could tune that, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: RfD Recognizer, 3rd version trans <transfire@gmail.com> - 2016-09-26 20:33 -0700
Re: RfD Recognizer, 3rd version Paul Rubin <no.email@nospam.invalid> - 2016-09-26 21:39 -0700
Re: RfD Recognizer, 3rd version tabcomputing@gmail.com - 2016-09-26 22:45 -0700
Re: RfD Recognizer, 3rd version Paul Rubin <no.email@nospam.invalid> - 2016-09-26 22:55 -0700
Re: RfD Recognizer, 3rd version Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-09-27 03:38 -0500
Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-27 12:42 +0000
Re: RfD Recognizer, 3rd version Bernd Paysan <bernd@net2o.de> - 2016-09-27 13:23 +0000
Re: RfD Recognizer, 3rd version trans <transfire@gmail.com> - 2016-09-27 19:09 -0700
Re: RfD Recognizer, 3rd version JennyB <jennybrien@googlemail.com> - 2016-09-28 00:07 -0700
Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-30 12:34 +0000
Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 10:03 +0200
Re: RfD Recognizer, 3rd version ruvim.pinka@gmail.com - 2016-09-28 02:39 -0700
Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-28 13:22 +0200
Re: RfD Recognizer, 3rd version anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-09-28 11:41 +0000
Re: RfD Recognizer, 3rd version albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2016-09-27 15:15 +0200
csiph-web