orochasamuel / fiscalbr-net

Para facilitar seu dia a dia como desenvolvedor \o/
MIT License
93 stars 49 forks source link

Atualizar campos de indicadores numéricos [INT to SHORT] #3

Closed orochasamuel closed 4 years ago

orochasamuel commented 5 years ago

Mudar de int para short.

Exemplo:

DE


            /// <summary>
            ///     Código do modelo do documento de arrecadação:
            ///     0 - documento estadual de arrecadação
            ///     1 - GNRE
            /// </summary>
            [SpedCampos(2, "COD_DA", "C", 1, 0, true)]
            public int CodDa { get; set; }

PARA


            /// <summary>
            ///     Código do modelo do documento de arrecadação:
            ///     0 - documento estadual de arrecadação
            ///     1 - GNRE
            /// </summary>
            [SpedCampos(2, "COD_DA", "C", 1, 0, true)]
            public short CodDa { get; set; }
orochasamuel commented 5 years ago

@ElemarJR você que é o "rei das otimizações" talvez possa me ajudar.

Compensa trocar os tipos int por short ou sbyte para esses casos específicos onde preciso de números bem pequenos? Se eu usar um tipo menor que 32 ou 64-bit não vai acontecer uma "conversão" em tempo de execução? Isso pode ser mais "custoso" do que benéfico? O que acha?

orochasamuel commented 4 years ago

Essa alteração não será mais implementada.

Performance-wise, an int is faster in almost all cases. The CPU is designed to work efficiently with 32-bit values.

Shorter values are complicated to deal with. To read a single byte, say, the CPU has to read the 32-bit block that contains it, and then mask out the upper 24 bits.

To write a byte, it has to read the destination 32-bit block, overwrite the lower 8 bits with the desired byte value, and write the entire 32-bit block back again.

Space-wise, of course, you save a few bytes by using smaller datatypes. So if you're building a table with a few million rows, then shorter datatypes may be worth considering. (And the same might be good reason why you should use smaller datatypes in your database)

And correctness-wise, an int doesn't overflow easily. What if you think your value is going to fit within a byte, and then at some point in the future some harmless-looking change to the code means larger values get stored into it?

Those are some of the reasons why int should be your default datatype for all integral data. Only use byte if you actually want to store machine bytes. Only use shorts if you're dealing with a file format or protocol or similar that actually specifies 16-bit integer values. If you're just dealing with integers in general, make them ints.

Fonte