Description:
The value returned by this function is a slice into an internal buffer. This buffer gets
reused between every call to this function.
So basically, if you don't need the guarentees of immutable (which toString will provide), and are aware
that the value from this function can and will change, then it is faster to use this function as otherwise, with toString,
a call to .idup is made.
Optimisation:
This function isn't terribly well optimised in all honesty, but that isn't really too bad of an issue because, at least on
my computer, it only takes around 2ms to create the output for a 180x180 grid, in the worst case scenario - where every character
requires a different ANSI code.
Worst case is O(3n), best case is O(2n), backtracking only occurs whenever a character is found that cannot be written with the same ANSI codes
as the previous one(s), so the worst case only occurs if every single character requires a new ANSI code.
Small test output - [WORST CASE | SHARED] ran 1000 times -> 1 sec, 817 ms, 409 us, and 5 hnsecs -> AVERAGING -> 1 ms, 817 us, and 4 hnsecs
While I haven't tested memory usage, by default all of the initial allocations will be (width * height) * 2, which is then reused between runs.
This function will initially set the internal buffer to width * height * 2 in an attempt to overallocate more than it needs.
This function caches its output (using the same buffer), and will reuse the cached output as long as there hasn't been any changes.
If there *have* been changes, then the internal buffer is simply reused without clearing or reallocation.
Finally, this function will automatically group together ranges of characters that can be used with the same ANSI codes, as an
attempt to minimise the amount of characters actually required. So the more characters in a row there are that are the same colour and style,
the faster this function performs.
Converts this TextBuffer into a string.
Description: The value returned by this function is a slice into an internal buffer. This buffer gets reused between every call to this function.
So basically, if you don't need the guarentees of immutable (which toString will provide), and are aware that the value from this function can and will change, then it is faster to use this function as otherwise, with toString, a call to .idup is made.
Optimisation: This function isn't terribly well optimised in all honesty, but that isn't really too bad of an issue because, at least on my computer, it only takes around 2ms to create the output for a 180x180 grid, in the worst case scenario - where every character requires a different ANSI code.
Worst case is O(3n), best case is O(2n), backtracking only occurs whenever a character is found that cannot be written with the same ANSI codes as the previous one(s), so the worst case only occurs if every single character requires a new ANSI code.
Small test output - [WORST CASE | SHARED] ran 1000 times -> 1 sec, 817 ms, 409 us, and 5 hnsecs -> AVERAGING -> 1 ms, 817 us, and 4 hnsecs
While I haven't tested memory usage, by default all of the initial allocations will be (width * height) * 2, which is then reused between runs.
This function will initially set the internal buffer to width * height * 2 in an attempt to overallocate more than it needs.
This function caches its output (using the same buffer), and will reuse the cached output as long as there hasn't been any changes.
If there *have* been changes, then the internal buffer is simply reused without clearing or reallocation.
Finally, this function will automatically group together ranges of characters that can be used with the same ANSI codes, as an attempt to minimise the amount of characters actually required. So the more characters in a row there are that are the same colour and style, the faster this function performs.