Performance vs Features: A Discussion About Sai's Future Direction

[aaronmallen]

Hi everyone, Aaron here!

I've been working on a significant performance refactor over the last few weeks and have achieved some excellent improvements in Sai, with some operations showing 50%+ performance gains compared to previous versions. However, when comparing Sai to other CLI color gems, we face an interesting tradeoff that I'd like the community's input on.

The Current Situation

One of Sai's distinctive features is its SequencedString object, returned when you call decorate. This object provides powerful manipulation capabilities:

s = Sai.red.on_blue.bold.underline.decorate("I'm an ANSI string")
s.to_s #=> "\e[38;5;160;48;5;21;1;4mI'm an ANSI string\e[0m"
s.without_background.to_s #=> "\e[38;5;160;1;4mI'm an ANSI string\e[0m"
s.without_foreground.to_s #=> "\e[48;5;21;1;4mI'm an ANSI string\e[0m"
s.without_style(:underline).to_s #=> "\e[38;5;160;48;5;21;1mI'm an ANSI string\e[0m"

It also enables detailed string segment analysis:

text = Sai.red.bold.decorate("Warning!")
text.each do |segment|
  puts "Text: #{segment.text}"
  puts "Foreground: #{segment.foreground}"
  puts "Background: #{segment.background}"
  puts "Styles: #{segment.styles}"
  puts "Encoded Position: #{segment.encoded_location.start_position}..#{segment.encoded_location.end_position}"
  puts "Stripped Position: #{segment.stripped_location.start_position}..#{segment.stripped_location.end_position}"
end

The Challenge

While these features are powerful, the parsing required for SequencedString is computationally expensive. Our benchmarks show that:

• With SequencedString as the default: Sai places last in both IPS and Memory benchmarks
• Without SequencedString: Sai consistently places second across all benchmarks
• The current first-place holder (paint) achieves its performance through a gzipped marshal dump of their color table, which would require limiting Sai's color palette - something we want to avoid

The Decision

We have two potential paths forward:

1. Keep SequencedString as the default, embracing our unique feature set despite lower benchmark performance
2. Make SequencedString opt-in through a breaking change, where string sequencing would work like this:

Sai.sequence(Sai.red.on_blue.bold.decorate('Hello, world!'))

I'd love to hear the community's thoughts on this tradeoff between default features and performance.

[jaredcwhite]

@aaronmallen For the opt-in option, could it just be an added DSL method? Like:

Sai.red.on_blue.bold.sequenced.decorate('Hello')

[aaronmallen]

I was thinking of something akin to Sai.red.decorate('Hello, world", sequence: true) but yes! The example posted in the discussion is just how you could replicate it via the current iteration of Sai

[collindonnell]

Does this matter in use? It's nice to make things fast, but if this is more of a theoretical problem, I'd leave it in favor of keeping whatever benefits it's providing. If this can't be improved and it is a problem in practice, @jaredcwhite's idea sounds like a smart compromise.

Could it be both? If you do the opt-in you get things exactly as they are, but if you opt-out you get the additional DSL method incase you need it for a special case? Maybe make it opt-out instead of opt-in?

[aaronmallen]

It doesn't really, at the end of the day we don't really NEED Sai to be fast it's just encoding strings with ANSI but consistently last place for one feature does admittedly feel bad.

[genericsteele]

My vote goes for a great developer experience by default that can be opted out of for performance considerations.

[karloscarweber]

My vote goes for a great developer experience by default that can be opted out of for performance considerations.

Same for me. You can always optimize later. No need to add to the workload. Being interesting and unique and fun is a value proposition beyond just speed too.