[RFC] Meta-data default behavior Relay astext API

[tqchen]

Background

We introduced the API relay_node.astext to dump relay code into text format. This can be useful for debugging purposes, so we can get text format out. In order to enable round-trip of between the text format and the in-memory one, we introduced a meta-data section to the text format. The metadata section can be used to store the content of the model parameters as relay.Constant in JSON format and is appended to the end of the text format.

Problem

The question is: should we set show_meta_data option in as text by default?

• currently it is set to True

• When we use astext for debugging, we want to skip printing meta_data section, because the base64 content of constants are meaningless and can be explosive

• When we use astext for serialization, we need to include meta_data, otherwise we cannot recover the data.

Possible Solutions

1. set default of show_meta_data to be False, and introduce perhaps new API such as save_xx for serialization.

2. keep the current API default(always print meta-data), but overload __str__ and ___repr__ of RelayNode to use astext. So we can use astext for serialziation, but use print directly for debug.

Please share your thoughts, cc @dmlc/tvm-comitter @jroesch

[zhiics]

I think it is probably worthy to have a separate API for serialization. Overloading can suppress meta in python, but we will still print it in c++ during debugging if False is not given.

[tqchen]

To unify the API, if we take the other way, astext defaults to show meta-data.

We can have also two functions in C++, AsText, which default to show meta-data, and Print, which by default do not show meta-data. We can also directly overload operator<< for the c++ side.

[zhiics]

Yes, then I don't have any preference. But sol. 2 looks cleaner.

[tqchen]

@jroesch what are your thoughts on this?

[ZihengJiang]

Prefer solution 2. When I try to debug the IR, I will try print(func) intuitively, but the information does not help a lot. So overloading __str__ sounds a good idea

[tqchen]

OK, seems everyone is leaning towards solution 2, contribution is welcomed

[tqchen]

#2533