perf: experiment with immutable strings

[reubeno]

No description provided.

[github-actions]

Test Results

    2 files      9 suites   1m 19s ⏱️
  572 tests   572 ✅ 0 💤 0 ❌
1 130 runs  1 130 ✅ 0 💤 0 ❌

Results for commit 47acd0e.

♻️ This comment has been updated with latest results.

[github-actions]

Performance Benchmark Report

Benchmark name	Baseline (μs)	Test/PR (μs)	Delta (μs)	Delta %
clone_shell_object	19.69 μs	19.27 μs	-0.42 μs	⚪ Unchanged
eval_arithmetic	0.47 μs	0.47 μs	-0.01 μs	⚪ Unchanged
expand_one_string	2.31 μs	2.28 μs	-0.03 μs	⚪ Unchanged
for_loop	63.72 μs	62.46 μs	-1.26 μs	🟢 -1.98%
function_call	5.07 μs	5.09 μs	0.02 μs	⚪ Unchanged
instantiate_shell	62.06 μs	62.20 μs	0.14 μs	⚪ Unchanged
instantiate_shell_with_init_scripts	28550.60 μs	29818.54 μs	1267.94 μs	🟠 +4.44%
parse_bash_completion	2856.38 μs	2707.99 μs	-148.39 μs	🟢 -5.19%
parse_sample_script	4.35 μs	4.49 μs	0.14 μs	⚪ Unchanged
run_echo_builtin_command	22.14 μs	22.24 μs	0.10 μs	⚪ Unchanged
run_one_external_command	1908.87 μs	1852.03 μs	-56.85 μs	🟢 -2.98%

[reubeno]

@39555 I'm interested to get your take since you've been looking at and thinking about parsing, tokenizing, and strings. Independent of parser approach (I.e. winnow/nom, peg, etc.), what do you think about looking at one of the many "low-cost clone" / CoW string crates? I encountered imstr but also see arcstr and a variety of others in similar category.

Given how much of the shell is string manipulation, I could see benefit but am concerned about how virally they spread in a code base and how much we'd get locked into them.

This draft is just an experiment in the parser crate. I imagine we'd see greater benefit by going more widespread and figuring out how to better work with them, where we can use the non-thread-safe variants, etc.

[39555]

@reubeno sorry for the long reply. Im currently out of my bandwidth. It is interesting concept! Is it basically an Arc? Do you share something like variable names across the codebase?