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 10:39:27 -05:00			`#[cfg(feature = "map")]`
			`mod map;`
refactor(dict): Make room for trie logic 2021-06-30 10:46:22 -05: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 16:03:09 -05: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 10:12:17 -05:00
feat(dict): Shared PHF support 2021-07-01 10:39:27 -05:00			`#[cfg(feature = "map")]`
			`pub use map::*;`
refactor(dict): Make room for trie logic 2021-06-30 10:46:22 -05: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 16:03:09 -05:00			`pub use trie::*;`