[Suggestions]: General suggestion for improvements

[DrunkenAlcoholic]

Excellent job on catnap, I have a few suggestions based on fetch utilities I have writen in both Pascal and Nim languages, I am also self taught, so I am no means giving you expert advice, and I am still very much a Noob when it comes to Nim, Saying that... I know enough to be able to suggest improvement to speed up catnap, in fact I have written a fetch in Nim to test a few things.

• Vui , consider removing this, you don't need it, the image is just a png image in a base64 string as per the kitty graphics protocol, however you may find the half blocks a useful fallback, up to you, if you do decide to implement image into catnap, I suggest you to look for the tpix project writen in Nim, is very easy to create the base64 string from a png image and its just an escape code for prefix and suffix which does the sizing.

• I also run a bit of a potato laptop from 2015, testing catnap I got around the same execution time as you describe ~0.006 seconds aka 6 milliseconds, however I am sure you can reduce that time by half. I have been using hyperfine for benchmarking these fetch utilities, and while I did start my Nim written fetch(nymph) with around 4ms I have since reduced that 2ms by defining my strings as const with static e.g

  
  const
  osReleasePath = static: "/etc/os-release"
  versionFile =   static: "/proc/version"
  packageDir =    static: "/var/lib/pacman/local"
  uptimeFile =    static: "/proc/uptime"
  meminfoPath =   static: "/proc/meminfo"
  secsPerDay =    static: 24 * 60 * 60
  gibDivisor =    static: 1024.0 * 1024.0
  mibDivisor =    static:1024

* The used memory is debatable in how its being calculated, while the implementation you have used is pretty much acceptable, htop and free use something like "iUsedMem = iMemTotal - (iMemFree + iBuffers + iCached) + (iShmem - iSReclaimable)" and yes I have  Nim if you wanted to calculate the same way. 

* Compiling flags, I noticed a good amount of improvements just adding a few flags to the compiler my current command for compiling Nim projects is 
```Nim
nim c  --passC:-flto --checks:off --panics:on --mm:arc --threads:on --opt:speed -d:danger src/nymph.nim

It probably doesn't need threads flag, as I haven't actually used multi-threading in the code, but I could improve my current 2ms execution time(with png image) down even further

• Another thing I notice a significant gain was the way I was writing the strings out to the console, and using stdout.flushfile() when I am done helped when running 10,000 benchmarks

• I noticed you have limited your color selection to basic 8 or so terminal escape color codes, Might be worth taking a look here on 24bit escape color codes as most terminals support this now, implementation is easy as its just RGB formatted in into the terminal escape code. I have added an example in Nim fetch I had written for testing.

I did upload my code as an example fetch utility, in case you did want to get some ideas from that. Saying that, these are just some random suggestions and ideas, if anything it may trigger something new for you to implement into catnap, if not then just ignore and delete this thread. https://github.com/DrunkenAlcoholic/Nymph

[iinsertNameHere]

Hey, thx for you feedback! I was actually planing to get rid of VUI for some time. Thx for the reference to tpix! The optimizations are also worth taking a look at.

[iinsertNameHere]

• [ ] Get rid of Vui
• [ ] Strings to const
• [ ] Use 24bit instead of 8bit colors

[DrunkenAlcoholic]

here is an example how the kitty protocol works to display png image, First prefix starts with escape code, the "_G" then you can add your key/value pairs, I have hard coded it "a=T" which tells the kitty protocol that we are transmitting, then the "f=100" is the type we are transmitting, in this case 100 = png then the payload which is the png encode to base64 string, then the escape code with "\" to end. you also need to send it in chunks of 4096 chars for the image, to let the kitty protocol know you set m=1 as part of the prefix that there are more to come, then on your last chunk set m=0. see the code below, also go and read the kitty graphics protocol https://sw.kovidgoyal.net/kitty/graphics-protocol/. this is just to display the image, you might want to also look at resizing the image before encoding it to base64, or do as I did in my example Nim fetch, hard code the logo as a base64 string into the program, but this will limit user being able to resize the image.

import base64, os

const 
  ESC = "\x1b"
  GrCmd = "a=T,f=100"

proc writeChunk(chunk: string, last: bool) =
  let payload = ESC & "_G" & GrCmd & ",m=" & (if last: "0" else: "1") & ";" & chunk & ESC & "\\"
  stdout.write payload
  stdout.flushFile()

proc main() =
  if paramCount() < 1:
    quit "Usage: " & getAppFilename() & " <png_file>"

  let 
    data = readFile(paramStr(1))
    encoded = base64.encode(data)

  for i in countup(0, encoded.high, 4096):
    let 
      chunk = encoded[i .. min(i + 4095, encoded.high)]
      last = i + 4096 > encoded.high
    writeChunk(chunk, last)

when isMainModule:
  main()

[yuki-was-taken]

I'm not sure if enabling the dangerous flag and disabling checks for compilation is good for normal use. The rest of the flags look alright though.

[DrunkenAlcoholic]

The assumption is you would have already compiled it at least once in a "debug" mode to know there are no issues, how ever the minimum you should compile it with is the "release" flag to turn on optimizations, "danger" does the same thing as "release" except it also turns off runtime checks. but valid points, if you feel having the debug data as part of the binary is useful for the user, then by all means keep it in, but don't expect fast execution times.