(bump to see this thread on narkive to see it from phone, weird narkive
dont show threads with only 1 post)
fir wrote:
(bump to see this thread on narkive to see it from phone, weird narkive
dont show threads with only 1 post)
there is hovever yet such weir option
its weird though convenient
struct Fir_List_Entry {int x, y;};
Fir_List_Entry* Fir_List = NULL;
int Fir_List_Size = 0;
Fir_List_Entry* Fir_List_New()
{
Fir_List = (Fir_List_Entry*) realloc(Fir_List, ++Fir_List_Size * sizeof(Fir_List_Entry) );
return &Fir_List[Fir_List_Size-1];
}
void Test()
{
*(Fir_List_New()) = {1,2};
*(Fir_List_New()) = {3,4};
*(Fir_List_New()) = {5,6};
for(int i=0; i<Fir_List_Size; i++)
printf("\n %d %d", Fir_List[i].x, Fir_List[i].y);
}
// sickle.h
struct str_list_entry { char* str;};
const int str_lists_max = 10;
str_list_entry* str_list[str_lists_max] = {NULL};
int str_list_size[str_lists_max] = {0};
str_list_entry* str_list_new(int N) {
str_list[N] = (str_list_entry*) realloc(str_list[N], ++str_list_size[N] * sizeof(str_list_entry) );
return &str_list[N][str_list_size[N]-1]; }
you know famous fir list
fir list its a list container i somewhat "invented",
i write "invented" as its reasonably simple thing but i never heard
anyone uses it so as for me i invented it for personal use and use it
some could usually wrote a more convenient Add "method" not to pass structures but just arguments and struct assigment do inside
On 28/03/2024 14:40, fir wrote:
you know famous fir list
fir list its a list container i somewhat "invented",
i write "invented" as its reasonably simple thing but i never heard
anyone uses it so as for me i invented it for personal use and use it
It's a pretty common thing though. It's just that it's not standard, so everyone does it pretty much in their own way.
In my way, I avoid to realloc the 'dynamic array' everytime a new item
is appended, as it can be a costly operation. I pre-allocate for a
certain number of items, and keep track of the current number of items
and the current size of the 'dynamic array'. If there is enough room
left, I just add the item, no realloc needed. If there isn't, then I
realloc, with not just room for 1 item, but a whole new block, for the
same reason. You get the idea.
This is a common way of dealing with such dynamic containers. (See: bump allocators, and all that...)
some could usually wrote a more convenient Add "method" not to pass
structures but just arguments and struct assigment do inside
From what I get - it's not fully clear - you'd like to directly pass a structure 'literal' to your function, rather than having to go via an intermediate local variable.
This is exactly what C99 has brought, among other things, for over 20
years. Do not hesitate to use it: compound literals.
For instance with your code, you can do this instead:
Fir_List_AddOne(&(struct Fir_List_Entry){ 11, 22 });
Yes, the 'cast' in front of the braces is mandatory for compound literals.
Note that your posted code is incorrect, you need to either refer to 'Fir_List_Entry' with 'struct Fir_List_Entry', or typedef it prior.
I think omitting the 'struct' is allowed in C++, not so in C.
Conversely, I'm not sure compound literals (which I find very handy) are available in C++. But if you were using C++, you wouldn't need to do the above anyway, so. Just mentioning it.
Opus wrote:
On 28/03/2024 14:40, fir wrote:
you know famous fir list
fir list its a list container i somewhat "invented",
i write "invented" as its reasonably simple thing but i never heard
anyone uses it so as for me i invented it for personal use and use it
It's a pretty common thing though. It's just that it's not standard, so
everyone does it pretty much in their own way.
In my way, I avoid to realloc the 'dynamic array' everytime a new item
is appended, as it can be a costly operation. I pre-allocate for a
certain number of items, and keep track of the current number of items
and the current size of the 'dynamic array'. If there is enough room
left, I just add the item, no realloc needed. If there isn't, then I
realloc, with not just room for 1 item, but a whole new block, for the
same reason. You get the idea.
This is a common way of dealing with such dynamic containers. (See: bump
allocators, and all that...)
some could usually wrote a more convenient Add "method" not to pass
structures but just arguments and struct assigment do inside
From what I get - it's not fully clear - you'd like to directly pass a
structure 'literal' to your function, rather than having to go via an
intermediate local variable.
This is exactly what C99 has brought, among other things, for over 20
years. Do not hesitate to use it: compound literals.
For instance with your code, you can do this instead:
Fir_List_AddOne(&(struct Fir_List_Entry){ 11, 22 });
Yes, the 'cast' in front of the braces is mandatory for compound
literals.
Note that your posted code is incorrect, you need to either refer to
'Fir_List_Entry' with 'struct Fir_List_Entry', or typedef it prior.
I think omitting the 'struct' is allowed in C++, not so in C.
Conversely, I'm not sure compound literals (which I find very handy) are
available in C++. But if you were using C++, you wouldn't need to do the
above anyway, so. Just mentioning it.
i think teh idea is rather not obvius, i agree people use dynamic
alocation, more rarely they use reallock atc but the pure idea
of list like here is imo not much in use imo... - if that would be in
use it would be generally used as this is some kind of composition
pattern and that would substitule ways people usually du such things
in c largely...as to the line you say i may test it
i coode in c++ mode and in c mode tu though in c++ more often
checked seem not to work: error: taking adress of temporary
as this list idea people may obviously take it uuse it and then say, oh,
i was using it - but in facy as i know how c people code (right from
this group etc) they dont use it, unless thay maybe begin using it in
last few years
when i started using it (see my more historic post about 'chunks' and 'splitter') i used the appproach with variable holding the preallocated value... then i dropped it becouse reallock already stores such number
under the hood so this is kinde reapeating the same thing - but then
later it showed that stiill doubling it may speed things becouse
(as far as i remember becouse i dont remember exact values ) this
call to reallock even if this do almosc nothing still may cost if this
is in more time critical case
Opus wrote:
On 28/03/2024 14:40, fir wrote:
you know famous fir list
fir list its a list container i somewhat "invented",
i write "invented" as its reasonably simple thing but i never heard
anyone uses it so as for me i invented it for personal use and use it
It's a pretty common thing though. It's just that it's not standard, so
everyone does it pretty much in their own way.
In my way, I avoid to realloc the 'dynamic array' everytime a new item
is appended, as it can be a costly operation. I pre-allocate for a
certain number of items, and keep track of the current number of items
and the current size of the 'dynamic array'. If there is enough room
left, I just add the item, no realloc needed. If there isn't, then I
realloc, with not just room for 1 item, but a whole new block, for the
same reason. You get the idea.
This is a common way of dealing with such dynamic containers. (See: bump
allocators, and all that...)
some could usually wrote a more convenient Add "method" not to pass
structures but just arguments and struct assigment do inside
From what I get - it's not fully clear - you'd like to directly pass a
structure 'literal' to your function, rather than having to go via an
intermediate local variable.
This is exactly what C99 has brought, among other things, for over 20
years. Do not hesitate to use it: compound literals.
For instance with your code, you can do this instead:
Fir_List_AddOne(&(struct Fir_List_Entry){ 11, 22 });
Yes, the 'cast' in front of the braces is mandatory for compound
literals.
Note that your posted code is incorrect, you need to either refer to
'Fir_List_Entry' with 'struct Fir_List_Entry', or typedef it prior.
I think omitting the 'struct' is allowed in C++, not so in C.
Conversely, I'm not sure compound literals (which I find very handy) are
available in C++. But if you were using C++, you wouldn't need to do the
above anyway, so. Just mentioning it.
i think teh idea is rather not obvius, i agree people use dynamic
alocation, more rarely they use reallock atc but the pure idea
of list like here is imo not much in use imo... - if that would be in
use it would be generally used as this is some kind of composition
pattern and that would substitule ways people usually du such things
in c largely...as to the line you say i may test it
i coode in c++ mode and in c mode tu though in c++ more often
checked seem not to work: error: taking adress of temporary
as this list idea people may obviously take it uuse it and then say, oh,
i was using it - but in facy as i know how c people code (right from
this group etc) they dont use it, unless thay maybe begin using it in
last few years
when i started using it (see my more historic post about 'chunks' and 'splitter') i used the appproach with variable holding the preallocated value... then i dropped it becouse reallock already stores such number
under the hood so this is kinde reapeating the same thing - but then
later it showed that stiill doubling it may speed things becouse
(as far as i remember becouse i dont remember exact values ) this
call to reallock even if this do almosc nothing still may cost if this
is in more time critical case
fir wrote:
Opus wrote:note i presented somewhat complicated versions of it (for structures,
On 28/03/2024 14:40, fir wrote:
you know famous fir list
fir list its a list container i somewhat "invented",
i write "invented" as its reasonably simple thing but i never heard
anyone uses it so as for me i invented it for personal use and use it
It's a pretty common thing though. It's just that it's not standard, so
everyone does it pretty much in their own way.
In my way, I avoid to realloc the 'dynamic array' everytime a new item
is appended, as it can be a costly operation. I pre-allocate for a
certain number of items, and keep track of the current number of items
and the current size of the 'dynamic array'. If there is enough room
left, I just add the item, no realloc needed. If there isn't, then I
realloc, with not just room for 1 item, but a whole new block, for the
same reason. You get the idea.
This is a common way of dealing with such dynamic containers. (See: bump >>> allocators, and all that...)
some could usually wrote a more convenient Add "method" not to pass
structures but just arguments and struct assigment do inside
From what I get - it's not fully clear - you'd like to directly pass a
structure 'literal' to your function, rather than having to go via an
intermediate local variable.
This is exactly what C99 has brought, among other things, for over 20
years. Do not hesitate to use it: compound literals.
For instance with your code, you can do this instead:
Fir_List_AddOne(&(struct Fir_List_Entry){ 11, 22 });
Yes, the 'cast' in front of the braces is mandatory for compound
literals.
Note that your posted code is incorrect, you need to either refer to
'Fir_List_Entry' with 'struct Fir_List_Entry', or typedef it prior.
I think omitting the 'struct' is allowed in C++, not so in C.
Conversely, I'm not sure compound literals (which I find very handy) are >>> available in C++. But if you were using C++, you wouldn't need to do the >>> above anyway, so. Just mentioning it.
i think teh idea is rather not obvius, i agree people use dynamic
alocation, more rarely they use reallock atc but the pure idea
of list like here is imo not much in use imo... - if that would be in
use it would be generally used as this is some kind of composition
pattern and that would substitule ways people usually du such things
in c largely...as to the line you say i may test it
i coode in c++ mode and in c mode tu though in c++ more often
checked seem not to work: error: taking adress of temporary
as this list idea people may obviously take it uuse it and then say, oh,
i was using it - but in facy as i know how c people code (right from
this group etc) they dont use it, unless thay maybe begin using it in
last few years
when i started using it (see my more historic post about 'chunks' and
'splitter') i used the appproach with variable holding the preallocated
value... then i dropped it becouse reallock already stores such number
under the hood so this is kinde reapeating the same thing - but then
later it showed that stiill doubling it may speed things becouse
(as far as i remember becouse i dont remember exact values ) this
call to reallock even if this do almosc nothing still may cost if this
is in more time critical case
longer names and indeksed a key (which is in fact dictionary)
quite useble would be tiny crafted versions of it - most simple
// "ints.h" - int list cntainer
int* ints = NULL; int ints_size = 0;
void ints_add(int val) {
ints = (int*)realloc(ints, ++ints_size*sizeof(int));
ints[ints_size-1] = val;
return ; }
//main.c
void Test()
{
ints_add(100);
ints_add(101);
ints_add(102);
ints_add(114);
for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
ints_size=0; //reset
ints_add(200);
ints_add(221);
ints_add(202);
ints_add(214);
for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
}
im not quite belive people use it as its such good idea if people would
use it it should be regularelly known and used and i never seen nor hear
of this (at least not before i get to use it few years ago)
people rather use c__ vectror sh*t instead of that and that is better
programming is a lot about composition and this changes composition
a lot
fir wrote:
fir wrote:
Opus wrote:note i presented somewhat complicated versions of it (for structures,
On 28/03/2024 14:40, fir wrote:
It's a pretty common thing though. It's just that it's not standard, so >>>> everyone does it pretty much in their own way.
you know famous fir list
fir list its a list container i somewhat "invented",
i write "invented" as its reasonably simple thing but i never heard
anyone uses it so as for me i invented it for personal use and use it >>>>
In my way, I avoid to realloc the 'dynamic array' everytime a new item >>>> is appended, as it can be a costly operation. I pre-allocate for a
certain number of items, and keep track of the current number of items >>>> and the current size of the 'dynamic array'. If there is enough room
left, I just add the item, no realloc needed. If there isn't, then I
realloc, with not just room for 1 item, but a whole new block, for the >>>> same reason. You get the idea.
This is a common way of dealing with such dynamic containers. (See:
bump
allocators, and all that...)
some could usually wrote a more convenient Add "method" not to pass
structures but just arguments and struct assigment do inside
From what I get - it's not fully clear - you'd like to directly pass a >>>> structure 'literal' to your function, rather than having to go via an
intermediate local variable.
This is exactly what C99 has brought, among other things, for over 20
years. Do not hesitate to use it: compound literals.
For instance with your code, you can do this instead:
Fir_List_AddOne(&(struct Fir_List_Entry){ 11, 22 });
Yes, the 'cast' in front of the braces is mandatory for compound
literals.
Note that your posted code is incorrect, you need to either refer to
'Fir_List_Entry' with 'struct Fir_List_Entry', or typedef it prior.
I think omitting the 'struct' is allowed in C++, not so in C.
Conversely, I'm not sure compound literals (which I find very handy)
are
available in C++. But if you were using C++, you wouldn't need to do
the
above anyway, so. Just mentioning it.
i think teh idea is rather not obvius, i agree people use dynamic
alocation, more rarely they use reallock atc but the pure idea
of list like here is imo not much in use imo... - if that would be in
use it would be generally used as this is some kind of composition
pattern and that would substitule ways people usually du such things
in c largely...as to the line you say i may test it
i coode in c++ mode and in c mode tu though in c++ more often
checked seem not to work: error: taking adress of temporary
as this list idea people may obviously take it uuse it and then say, oh, >>> i was using it - but in facy as i know how c people code (right from
this group etc) they dont use it, unless thay maybe begin using it in
last few years
when i started using it (see my more historic post about 'chunks' and
'splitter') i used the appproach with variable holding the preallocated
value... then i dropped it becouse reallock already stores such number
under the hood so this is kinde reapeating the same thing - but then
later it showed that stiill doubling it may speed things becouse
(as far as i remember becouse i dont remember exact values ) this
call to reallock even if this do almosc nothing still may cost if this
is in more time critical case
longer names and indeksed a key (which is in fact dictionary)
quite useble would be tiny crafted versions of it - most simple
// "ints.h" - int list cntainer
int* ints = NULL; int ints_size = 0;
void ints_add(int val) {
ints = (int*)realloc(ints, ++ints_size*sizeof(int));
ints[ints_size-1] = val;
return ; }
(btw i consider such containers to be a part of my sickle.c library )
one could also write a one line add version, i hope its right
int* ints = NULL; int ints_size = 0;
void ints_add(int val){(ints=(int*)realloc(ints,++ints_size*sizeof(int)))[ints_size-1]=val;}
if that would be so common people wouldnt talk about crap c++ vector so
much
//main.c
void Test()
{
ints_add(100);
ints_add(101);
ints_add(102);
ints_add(114);
for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
ints_size=0; //reset
ints_add(200);
ints_add(221);
ints_add(202);
ints_add(214);
for(int i=0; i<ints_size;i++) printf("\n%d", ints[i]);
}
im not quite belive people use it as its such good idea if people would
use it it should be regularelly known and used and i never seen nor hear
of this (at least not before i get to use it few years ago)
people rather use c__ vectror sh*t instead of that and that is better
programming is a lot about composition and this changes composition
a lot
one could also write a one line add version, i hope its right
int* ints = NULL; int ints_size = 0;
void ints_add(int val){(ints=(int*)realloc(ints,++ints_size*sizeof(int)))[ints_size-1]=val;}
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);ÿ }
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.
bart wrote:
On 30/03/2024 09:56, fir wrote:i know its inneficient but that was not the point - the point was more
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.
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;
fir wrote:
bart wrote:
On 30/03/2024 09:56, fir wrote:i know its inneficient but that was not the point - the point was more
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.
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
fir wrote:
fir wrote:
bart wrote:
On 30/03/2024 09:56, fir wrote:i know its inneficient but that was not the point - the point was more
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.
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
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;
}
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.
fir wrote:
fir wrote:
bart wrote:
On 30/03/2024 09:56, fir wrote:i know its inneficient but that was not the point - the point was more
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.
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,
fir wrote:
fir wrote:
bart wrote:
On 30/03/2024 09:56, fir wrote:i know its inneficient but that was not the point - the point was more
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.
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
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;
}
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 7 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 130:02:02 |
| Calls: | 46 |
| Files: | 21,492 |
| Messages: | 64,855 |