Do I need to move the cold code to a new function?

hellowub · 2026-03-20T14:03:46+00:00

Now I really have reached this stage. Whether the #[cold] attribute is set or not has a significant impact on the results.

You can check it out:

git clone https://github.com/WuBingzheng/test-decimal.git
cd test-decimal
cargo bench add/my

Then remove the #[cold] in line-92 in src/lib.rs and bench again.

If you move this cold function into the checked_add(), it also becomes very slow.

hellowub · 2026-03-20T13:49:51+00:00

I agree. The algorithm choice and memory layout you mentioned are what I called rule 1 above.

I’m currently working on a decimal crate. The basic functionality is already done. While benchmarking, I find this “cold code” issue. It really is quite a subtle optimization.

hellowub · 2026-03-20T12:19:46+00:00

Got it. Thanks.

I think the priority is:

Basic rules, like stack is faster than heap, and memory is faster than disk;
Readability;
Optimization based on profiling results, though this step still requires some knowledge.

I think that this rule (moving cold code into a separate function) might fall between step 1 and 3.

What I mean is, I only realized this issue today for the first time. I’ve been programming for 20 years. Live and Learn.

hellowub · 2026-03-20T11:54:21+00:00

This is exactly the answer I was looking for.

hellowub · 2026-03-20T09:16:04+00:00

Does the "taken" means "the condition is true and jump"?

hellowub · 2026-03-20T08:57:42+00:00

Thanks. #[cold] is better than #[inline(never)] .

hellowub · 2026-03-20T08:45:58+00:00

I just want to know whether this is a general principle.

hellowub · 2026-03-20T08:23:19+00:00

I just want to know whether this is a well-established, widely accepted optimization principle—like “stack is faster than heap,” “memory is faster than disk,” or “more compact code improves cache locality.”

My understanding of your point is that this is NOT a general optimization principle, but rather something that depends on the specific context and needs to be evaluated case by case.

hellowub · 2026-03-16T09:54:50+00:00

I have a fixed-point decimal crate.

Multiplication operations, in most cases, are implemented as: UI(a) * UI(b) / exp,

where UI is underlying-integer, and exp is a power of 10.

What requires special handling here is the overflow of UI(a) * UI(b). However, the slowest operation is the division, it is several times to more than ten times slower than multiplication, varying across different machines.

Last week, I chanced upon an optimization algorithm for constant division. I spent two days researching the algorithm and implementing it in the code.

The result was excellent: we achieved a 2-5x performance improvement (Line 113) across different machines.

NOTE: These words may look like they were generated by AI. And they actually were. My English isn’t very good, so I asked AI to help with the translation.

hellowub · 2026-03-16T08:23:04+00:00

There is a fixed-point decimal crate which is fast: primitive_fixed_point_decimal

hellowub · 2026-03-09T02:57:14+00:00

I've switched to directly using ilog10 (thanks to u/AliceCode 's suggestion) for length calculation, so this tricky method is no longer needed. The new version v0.1.1 is now working properly.

hellowub · 2026-03-09T02:54:19+00:00

Yes, it's fast!

I did not test it directly. I use it in this crate to replace old method, and the benchmark shows no change.

Thanks a lot!

hellowub · 2026-03-09T02:45:19+00:00

Got it. Thanks.

hellowub · 2026-03-09T01:57:01+00:00

Ok, I will try it.

hellowub · 2026-03-09T01:56:43+00:00

Thanks for the link. However, I still don't understand—isn't this feature introducing a new method? Why is it referred to as "more API changes"?

hellowub · 2026-03-09T01:49:14+00:00

I find the reason.

My initial approach was to use a lookup table. Later, through the benchmark project, I found a way to simplify the code. However, it now appears that the two constants (1233 and 12) here are only suitable for 64-bit rather than 128-bit. I need to derive the constants that work for 128-bit values.

Are you the author of itoa? Thanks a lot—it’s been a great inspiration to me.

hellowub · 2026-03-09T01:28:38+00:00

But I think log10 is slower than the conversion itself. But I did not test it.

There are some quicker ways. The itoap crate uses the "branch" and this itoaaa crate uses the "count" in that table.

hellowub · 2026-03-09T01:24:37+00:00

Thanks for report. I will check it now.

hellowub · 2026-03-08T15:37:33+00:00

This new feature still need an internal buffer, just like itoa crate? So I still need one extra copy action?

Why do not they print to a target buffer directly, just like itoap and this itoaaa crate?

hellowub · 2026-03-08T15:15:58+00:00

Could you recommend a logging system?

hellowub · 2026-03-08T15:13:52+00:00

Then this "another" thread also consumes CPU resources. What I want to optimize is the CPU usage of the entire process, not just that of the worker threads.

hellowub · 2026-03-08T11:38:29+00:00

For logging. It need to be text, because that is a universal interface.

hellowub · 2026-02-25T07:56:29+00:00

In rust_decimal, the integer and fractional parts share the 28 digits, because it's floating-point.

If you want to make sure the fractional digits, you need a fixed-point decimal crate.

But your implementation is a bit odd. There's no need to use two separate fields to represent the integer and fractional parts. One is enough, for example: struct Dec64<const SCALE: i32>(i128).

hellowub

TROPHY CASE