typos/crates/dictgen/src/lib.rs

#[cfg(feature = "map")]
mod map;
mod table;
mod trie;

#[cfg(feature = "map")]
pub use map::*;
pub use table::*;
pub use trie::*;
feat(dict): Shared PHF support 2021-07-01 11:39:27 -04:00			`#[cfg(feature = "map")]`
			`mod map;`
refactor(dict): Make room for trie logic 2021-06-30 11:46:22 -04:00			`mod table;`
perf(dict): Switch varcon to a burst-trie This cuts varcon lookup times in half but I still suspect slower than phf. Like with bsearch and unlike, the cost is consistent between hits and misses. At least this doesn't have the compile hit of PHF + unicase. Maybe I should experiment with integrating a non-const-fn variant of unicase with PHF and give up on all of this extra complexity. 2021-06-30 17:03:09 -04:00			`mod trie;`
refactor(dict): Pull out table-lookup logic Before, only some dicts did we guarentee were pre-sorted. Now, all are for-sure pre-sorted. This also gives each dict the size-check to avoid lookup. But this is really about refactoring in prep for playing with other lookup options, like tries. 2021-06-30 11:12:17 -04:00
feat(dict): Shared PHF support 2021-07-01 11:39:27 -04:00			`#[cfg(feature = "map")]`
			`pub use map::*;`
refactor(dict): Make room for trie logic 2021-06-30 11:46:22 -04:00			`pub use table::*;`
perf(dict): Switch varcon to a burst-trie This cuts varcon lookup times in half but I still suspect slower than phf. Like with bsearch and unlike, the cost is consistent between hits and misses. At least this doesn't have the compile hit of PHF + unicase. Maybe I should experiment with integrating a non-const-fn variant of unicase with PHF and give up on all of this extra complexity. 2021-06-30 17:03:09 -04:00			`pub use trie::*;`