Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!weretis.net!feeder6.news.weretis.net!i2pn.org!i2pn2.org!.POSTED!not-for-mail
From: fir
Newsgroups: comp.lang.c
Subject: Re: macro for fir list?
Date: Sat, 30 Mar 2024 15:54:18 +0100
Organization: i2pn2 (i2pn.org)
Message-ID:
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 30 Mar 2024 14:54:14 -0000 (UTC)
Injection-Info: i2pn2.org;
logging-data="3726156"; mail-complaints-to="usenet@i2pn2.org";
posting-account="+ydHcGjgSeBt3Wz3WTfKefUptpAWaXduqfw5xdfsuS0";
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24
In-Reply-To:
X-Spam-Checker-Version: SpamAssassin 4.0.0
Bytes: 5750
Lines: 135
fir wrote:
> fir wrote:
>> fir wrote:
>>> bart wrote:
>>>> On 30/03/2024 09:56, fir wrote:
>>>>
>>>>>>
>>>>> yet other example
>>>>>
>>>>> //bytes container
>>>>> char* bytes = NULL; int bytes_size = 0;
>>>>> void bytes_add(char val) {
>>>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>>>
>>>>>
>>>>>
>>>>> }
>>>>> void bytes_load(char* name) { FILE *f = fopen(name, "rb"); int
>>>>> c; while((c=getc(f))!=EOF) bytes_add(c); fclose(f); }
>>>>
>>>> This is pretty inefficient. Loading an 8MB file this way takes 3
>>>> seconds, vs. 50ms to load it in one go.
>>>>
>>>> Loading the same 90KB file 10,000 times took 120 seconds, vs. 0.8
>>>> seconds even using a scripting language.
>>>>
>>>> 80% of the inefficiency is growing the buffer one byte at a time. The
>>>> other 20% is reading the file one byte at a time.
>>>>
>>>>
>>> i know its inneficient but that was not the point - the point was more
>>> about composition and utility
>>>
>>> i may revrite but the example would be much longer
>>>
>>> char* bytes = NULL; int bytes_size = 0;
>>> char* bytes_resize(char size) {return
>>> bytes=(char*)realloc(bytes,(bytes_size=size)*sizeof(char)); }
>>> void bytes_add(char val) {
>>> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
>>>
>>>
>>> }
>>> void bytes_save(char* name) { FILE* f =fopen(name, "wb"); int
>>> saved = fwrite (bytes , 1, bytes_size, f); fclose (f); }
>>>
>>>
>>> int GetFileSize2(char *filename)
>>> {
>>> struct stat st;
>>> if (stat(filename, &st)==0) return (int) st.st_size;
>>> // ERROR_EXIT("error obtaining file size for &s", filename);
>>> return -1;
>>> }
>>>
>>> void bytes_load(char* name)
>>> {
>>> int flen = GetFileSize2(name);
>>> FILE *f = fopen(name, "rb");
>>> int loaded = fread(bytes_resize(flen), 1, flen, f);
>>> fclose(f);
>>> }
>>>
>>> generally if some uses this bytes microcintainer (i call it also list,
>>> though it is also resizable array) one may use thie add method which
>>> callst reallock or call resize(1000) and use it by bytes[i] so its not
>>> inefficient
>>>
>>> //@include "bytes.c"
>>> for(int i=0;i<1000;i++) bytes_add(rand()&0xff);
>>>
>>> bytes_resize(1000);
>>> for(int i=0;i<1000;i++) bytes[i]=rand()&0xff;
>>>
>>
>> yoy may check how much it last to say insert 1M of bytes by add compared
>> to resize and put it normall way - thic could measure overhead of this
>> reallock... i may add this variable say _cached_size or what to name it,
>> its a line of code ot wo and that will speed up but there still be a
>> cost of if
>
>
> i made some test with putting 1M by add it takes 160 ms
> 10M by cahced add 45 ms and 10M stright 7 ms, 10M by firs approch may
> take more than 10x 160 ms becouse i drwa a plot and if its plots so slow
> i dont wait,
>
> if so it seems that this reallock is badly designed or what becouse
> it shouldnt be so much slow imo - i vaguelly remember there was
> iek already talko on this here..meybe becouse some multithreading
> things or what (calling across dll barrier shouldnt be so slow per
> se - it also seems i got some slight bug in the test
>
> if(_1_pressed) { bytes_size=0; for(int i=0; i<1*1024*1024; i++)
> bytes_add(0x55); }
> if(_2_pressed) { bytes_size=0; for(int i=0; i<10*1024*1024; i++)
> bytes_add_cached(0x55); }
> if(_3_pressed) { bytes_resize(10*1024*1024); for(int i=0;
> i<10*1024*1024; i++) bytes[i]=0x55; }
>
> becouse all is okai untill i press 1 2 1 2 and now its segfault
> but my head hurts today a bot and im not sure i even want to search fr
> that bug now
>
ah, i know its obvious..i should use two separete seens as when i ussed
thich cached one i may assume i reallocked cached amount and when i
press 1 i reallock the same sid and i guess it reallocks it down so then
cached one accesses above the limit
>
> char* bytes = NULL; int bytes_size = 0;
>
> char* bytes_resize(int size)
> {
> return bytes=(char*) realloc(bytes, (bytes_size=size)*sizeof(char));
> }
>
> void bytes_add(char val) {
> (bytes=(char*)realloc(bytes,++bytes_size*sizeof(char)))[bytes_size-1]=val;
> }
>
> void bytes_add_cached(char val) {
> static int cached_size = 0;
> bytes_size++;
> if(bytes_size<=cached_size);
> else
> bytes=(char*)realloc(bytes,(cached_size=(bytes_size+100)*10)*sizeof(char));
>
> bytes[bytes_size-1]=val; return;
>
> }
>
>
>