Currently BorshSchema has static but not constant methods. These methods when compiled to Wasm occupy significant space. Also, they create a significant execution overhead when self-described borsh deserialization/serialization is called using https://docs.rs/borsh/0.6.2/borsh/schema_helpers/index.html
To fix it we need to implement const version of BorshSchema:: schema_container(). Unfortunately, it means two things:
We can only use types allowed by the const context;
schema_container() cannot return a type that requires allocation.
We currently intend to serialize BorshSchemaContainer using either borsh or JSON. Therefore we can have two versions of schema_container():
schema_container_borsh() -> &[u8];
schema_container_json() -> &str;
Both return container in already serialized form. Then we can allow reconstructing BorshSchemaContainer from it, if necessary.
schema_container_json internally would define const variables for each type and recursively concatenate them using std::concat. As the result, each type will have a compile-time computed schema. Similar technique can be used with byte slices and schema_container_borsh.
This will improve performance in the following way:
If we want to serialize a self-described borsh type using https://docs.rs/borsh/0.6.2/borsh/schema_helpers/index.html the helper will use schema_container_borsh to prepend an already generated sequence of bytes in front the borsh serialized object. Upon deserialization of that object the helper will check that the schema in the self-described type matches the schema of the type is deserializes it into.
Wasm will have hardcoded schemas instead of the code that generates them.
Currently
BorshSchemahas static but not constant methods. These methods when compiled to Wasm occupy significant space. Also, they create a significant execution overhead when self-described borsh deserialization/serialization is called using https://docs.rs/borsh/0.6.2/borsh/schema_helpers/index.htmlTo fix it we need to implement const version of
BorshSchema:: schema_container(). Unfortunately, it means two things:schema_container()cannot return a type that requires allocation.We currently intend to serialize
BorshSchemaContainerusing either borsh or JSON. Therefore we can have two versions ofschema_container():schema_container_borsh() -> &[u8];schema_container_json() -> &str; Both return container in already serialized form. Then we can allow reconstructingBorshSchemaContainerfrom it, if necessary.schema_container_jsoninternally would defineconstvariables for each type and recursively concatenate them usingstd::concat. As the result, each type will have a compile-time computed schema. Similar technique can be used with byte slices andschema_container_borsh.This will improve performance in the following way:
schema_container_borshto prepend an already generated sequence of bytes in front the borsh serialized object. Upon deserialization of that object the helper will check that the schema in the self-described type matches the schema of the type is deserializes it into.