Sujet : Re: filling area by color atack safety - worst memory size
De : already5chosen (at) *nospam* yahoo.com (Michael S)
Groupes : comp.lang.cDate : 17. Apr 2024, 20:41:26
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20240417224126.0000727a@yahoo.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
On Wed, 17 Apr 2024 10:47:25 -0700
Tim Rentsch <
tr.17687@z991.linuxsc.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
[...]
Finally found the time for speed measurements. [...]
I got these. Thank you.
The format used didn't make it easy to do any automated
processing. I was able to get around that, although it
would have been nicer if that had been easier.
The results you got are radically different than my own,
to the point where I wonder if there is something else
going on.
What are your absolute result?
Are they much faster, much slower or similar to mine?
Also it would help if you find out characteristics of your test
hardware.
Considering that, since I now have no way of doing any
useful measuring, it seems there is little point in any
further development or investigation on my part. It's
been fun, even if ultimately inconclusive.
I am still interested in combination of speed that does not suck
with O(N) worst-case memory footprint.
I already have couple of variants of the former, but so far they are
all unreasonably slow - ~5 times slower than the best.