Render anything inline. Save sessions and history. Powered by open web standards.

I’m trying it, and it does looks nice.

  • Daniel Quinn@lemmy.ca
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    1
    ·
    11 months ago

    I never understand the whole thing around “fast” terminals. How can a terminal be “slow”? Surely the terminal you’re using has no effect on the programs you’re calling, so what’s being measured here?

    • flubba86@lemmy.world
      link
      fedilink
      arrow-up
      3
      ·
      11 months ago

      I get what you mean, it is an interesting question to explore.

      For me, it think it appeals to my obsessive engineer-brain, I am hooked on chasing efficiency.

      Eg, if one tool uses 10MB ram and takes 1second to complete a task, and another tool takes 50MB ram and 5 seconds to complete the same task, then clearly I want to use the more efficient one. The other must be wasting resources, right?

      When it comes to real life software and real tasks, it is a lot more complicated than that, there are hundreds of variables to take into account and compare. But if one tool stands out among the others, optimising to achieve the best number (fastest time, lowest power draw, lowest ram use, etc) in each comparable variable, then I absolutely must use that one, it would be irresponsible not to, right?

      Throw hardware acceleration into the mix, and it takes the situation to a new level. Why make my poor CPU render the text on the screen 60 times per second, when I can get the GPU to do it? It’s just sitting there doing nothing, and it’s better at the job anyway, and as a bonus you get even lower CPU utilisation and lower ram usage.

      However, as I described in my previous post, chasing these numbers can come at the cost of usability. That’s the case with Alacritty, and why I will be switching to wezterm.