[GitHub] [arrow] Platob opened a new issue, #35175: [C#] Decimal128 / 256 Builders should alloc dynamic byteWidth based on precision and scale

["Platob (via GitHub)" <gi...@apache.org>]

Platob opened a new issue, #35175:
URL: https://github.com/apache/arrow/issues/35175

   ### Describe the enhancement requested
   
   Builder(Decimal128Type type) : base(type, 16)
   Builder(Decimal256Type type) : base(type, 32)
   
   ### Component(s)
   
   C#


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@arrow.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [arrow] felipecrv closed issue #35175: [C#] Decimal128 / 256 Types should alloc dynamic byteWidth based on precision and scale

["felipecrv (via GitHub)" <gi...@apache.org>]

felipecrv closed issue #35175: [C#] Decimal128 / 256 Types should alloc dynamic byteWidth based on precision and scale
URL: https://github.com/apache/arrow/issues/35175


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

[GitHub] [arrow] felipecrv commented on issue #35175: [C#] Decimal128 / 256 Types should alloc dynamic byteWidth based on precision and scale

["felipecrv (via GitHub)" <gi...@apache.org>]

felipecrv commented on issue #35175:
URL: https://github.com/apache/arrow/issues/35175#issuecomment-1513326147

   I'm closing this issue as you already closed the associated PR and I will answer some of your comments here with more  details on the ratinale.
   
   > I saw in ParquetSharp implementation returning a Decimal128Type with 9 byteWidth for precision = 15 and scale = 5 which was different from 16
   > 
   > I wonder why its fixed since it could use way less memory for small numbers
   
   Fixed length types simplify the compute kernels for both the programmer (less checks to be made) and CPU execution: things are more predictable (less branches), addresses are aligned on a power of 2, and easily calculable (multiplying by 2^k is just a shift instruction and memory loading CPU instructions can often do that by themselves).
   
   If memory consumption is the main concern, a new type would have to be introduced (`VarDecimal`) as all the integrations with these arrow types rely on them being fixed width.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: github-unsubscribe@arrow.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org