The version currently used is allocating and setting up the type matchers definition at each call to Infer::new, while this is not necessary. Version 0.2.3 uses static matcher definitions making Infer::new much cheaper.
To be honest I have not performed any benchmark on this, but the code is pretty obvious. I believe that http-types being used at the art of http applications should be as cheap as possible as far as memory and cpu is concerned.
Note: I am also contributing to Infer. There are lots of changes discussed there to try to bring an as cheap as possible experience for type checking. We are also discussing with other mime related crates (mime_guess, mime_db in particular) to deliver a consistent API for all "mime and file extension guessing utilities". Once everything is stabilized we will be able to offer a fully no_alloc version that would clearly benefit for http-types. Meanwhile version 0.2.3 is already a benefit for http-types.
The version currently used is allocating and setting up the type matchers definition at each call to
Infer::new, while this is not necessary. Version 0.2.3 uses static matcher definitions making Infer::new much cheaper.To be honest I have not performed any benchmark on this, but the code is pretty obvious. I believe that
http-typesbeing used at the art of http applications should be as cheap as possible as far as memory and cpu is concerned.Note: I am also contributing to
Infer. There are lots of changes discussed there to try to bring an as cheap as possible experience for type checking. We are also discussing with other mime related crates (mime_guess, mime_db in particular) to deliver a consistent API for all "mime and file extension guessing utilities". Once everything is stabilized we will be able to offer a fullyno_allocversion that would clearly benefit forhttp-types. Meanwhile version 0.2.3 is already a benefit forhttp-types.Cheers.