@rogday, thank you for the patch.

one general question and one general request.

the question. Could you please list the reasons why is this refactoring done. I mean, we discussed it briefly during the core team meeting and we found some pro's and con's of such approach:

pro's:

• parsing each layer info is more atomic
• maybe parsers of new layers can be added externally (even though you explicitly use pointers to methods rather than functions).
• the speed is a bit higher because the efficient O(1) or O(logN) search in dictionary is used instead of linear search across the supported layers. However, disk I/O is probably the main bottleneck that limits the import speed.

con's:

• there is more code
• in each and every method the same prologue is used, which can be avoided in the case a single if-elseif cascade. More generally, if some layers are similar, they can share some parts, whereas in the new approach all this code needs to be duplicated. Together with the code duplication comes the satellite problem of consistency of the updates. If we need to add or change some common preprocessing in layer parsing, we'd need to replicate these changes in each single method.

Maybe I missed something. If so, can you please put your thoughts?

the request. If we decide to keep this structure, I think, the methods need to be renamed to include some common prefix, e.g. parse. That is, instead of "concat", the method should possibly be named "parseConcat". It will help to avoid possible name conflicts if the different parsers API needs to be extended with some functionality that this functionality will conflict with a layer name.

@vpisarev, thank you for the review.

This refactoring is done because I plan to implement TF importer diagnostic similar to ONNX one. In the latter each layer is duplicated in registered set(which is used for diagnostic reasons) and in if-elseif cascade, which makes it easy to forget to add the layer everywhere. It's also more structured this way and can be navigated more easily. The prologue can be inlined since its just introducing constant reference most of the time, and it is pretty short. If the layers share common parts, these parts can be turned into functions themselves. Or it can be done just like in convolution function which branches based on the type of the layer.

@rogday, thank you. It's good enough explanation for me.

@alalek, together with@rogday we briefly discussed this PR during the meeting. How about to create the map of the layer names and the parsing functions dynamically, each time a model is loaded? It's super-little overhead both in terms of consumed memory (probably just a few Kb) and time (I guess, far below <1ms). Such a solution will completely eliminate the need to use mutex and worry about proper deallocation of the map at the end.

This makes sense. Also this would help to configure possible custom handlers in flexible way.