Path: csiph.com!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: filling area by color atack safety - worst memory size Date: Fri, 19 Apr 2024 14:59:20 -0700 Organization: A noiseless patient Spider Lines: 52 Message-ID: <86a5lpxbd3.fsf@linuxsc.com> References: <86h6h3nvyz.fsf@linuxsc.com> <865xxiok09.fsf@linuxsc.com> <20240319131842.00002138@yahoo.com> <86o7b9ms7d.fsf@linuxsc.com> <20240320115416.00001ab5@yahoo.com> <86zfusltwp.fsf@linuxsc.com> <20240324193352.000062e9@yahoo.com> <86jzlrk0f6.fsf@linuxsc.com> <20240405173033.00006145@yahoo.com> <868r1k1uq8.fsf@linuxsc.com> <20240411152033.00007173@yahoo.com> <86bk6ez9te.fsf@linuxsc.com> <20240417004609.000010aa@yahoo.com> <86plunyj82.fsf@linuxsc.com> <20240417224126.0000727a@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 19 Apr 2024 23:59:23 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0518bb4613e9ed3dcecbcbf6c934dda9"; logging-data="3392588"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/fYhZI42Cdn4etupAoxabeHxyYeLByh1s=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:MoXBFBm9XHhvd0bEuoBjtHdjjQk= sha1:TwaMyGgj6Ax/sBASloC+NiEFX7U= Xref: csiph.com comp.lang.c:384370 Michael S writes: > On Wed, 17 Apr 2024 10:47:25 -0700 > Tim Rentsch wrote: > >> Michael S 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. I think trying to look at those wouldn't tell me anything helpful. Too many unknowns. And still no way to test or measure any changes to the various algorithms. >> 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, Did you mean you some algorithms whose worst case memory behavior is strictly less than O( total number of pixels )? I think it would be helpful to adopt a standard terminology where the pixel field is of size M x N, otherwise I'm not sure what O(N) refers to. > but so > far they are all unreasonably slow - ~5 times slower than > the best. I'm no longer working on the problem but I'm interested to hear what you come up with.