refactor: replace format! with concat! for string literals

[Integral-Tech]

• Although format! macro is very powerful, it introduces overhead of memory allocation on the heap compared to &str. Therefore, when format! macro is unnecessary, we should avoid using it.

[ricvelozo]

I think the format macro already optimizes static strings (like the env! ones).

See: https://blog.m-ou.se/format-args/#small-steps

[Integral-Tech]

I think the format macro already optimizes static strings (like the env! ones).

See: https://blog.m-ou.se/format-args/#small-steps

They are different. concat!() constructs the &str during compilation, which is still faster.

[ricvelozo]

I think the format macro already optimizes static strings (like the env! ones).

See: https://blog.m-ou.se/format-args/#small-steps

They are different. concat!() constructs the &str during compilation, which is still faster.

Read the link I wrote.

[Integral-Tech]

@ricvelozo I have read your link, it says format_args()! can inline static strings.
However, format!() is equivalent to fmt::format(format_args!()). The function fmt::format still involves heap allocation.
If you don't like using concat!(), format_args!().as_str() can be used instead to avoid heap allocation.

[ricvelozo]

@ricvelozo I have read your link, it says format_args()! can inline static strings.
However, format!() is equivalent to fmt::format(format_args!()). The function fmt::format still involves heap allocation.
If you don't like using concat!(), format_args!().as_str() can be used instead to avoid heap allocation.

Like I said in the review, you are using the ToString trait, and that allocates.

[Integral-Tech]

@ricvelozo I have just removed the change that involves .to_string() call :)

[ricvelozo]

@ricvelozo I have just removed the change involves .to_string() call :)

Nice! 👍🏻

[Integral-Tech]

@ricvelozo Could you please approve the workflow run?

[ricvelozo]

@ricvelozo Could you please approve the workflow run?

Needs Héctor's approval. Eventually he will review.

[Koranir]

All these usecases convert the given input into a PathBuf anyways, which does allocate and copy if made with static string slice data. PathBufs don't allocate if created from a String, so this PR doesn't really change anything to do with allocation amounts.