Re: slow startup on windows

Roland Hughes via Foxgui-users <[email protected]> Mon, 28 Oct 2024 09:08:15 -0500
Newsgroups gmane.comp.lib.fox-toolkit.user
Message-ID <[email protected]>
Not really a mystery. Microsoft has had a sucky compiler since they 
abandoned Lattice and wrote their own back in the days of DOS. Memory 
allocation has sucked since the days of the 386.

Many application frameworks also pre-extend. I don't know if FOX does, 
but many will have a minimum number of entries they create for each 
container type even when container is empty. They do this to get around 
sucky compilers and run-times. Usually there is a constant somewhere one 
can tweak to change from say 100 to 5 or whatever.

While this and any framework's developers can do their damndest to make 
an append() as efficient as possible in the C/C++ code, they are at the 
mercy of the OS and C/C++ run-time library. This all goes back to the 
very first long email I sent on this thread.

Your container has a chunk. The runtime gets a request to extend the 
chunk but the OS wants containers kept contiguous whenever possible. 
Your application (or something else) allocated the RAM physically next 
to the chunk owned by your container. OS mandates a move to a new chunk 
of RAM. Everything has to be copied. Most assembly languages (and CPUs) 
have a block-move instruction no matter what they call it. Some may even 
have fancy schmancy RAM controllers which can be delegated the 
block-move task. Still, data has to take the bus from one part of RAM to 
another. It might be a little bus inside the RAM controller or the main 
bus everybody is riding, but it has to take the bus.

Linked lists and pointer arrays were very popular in the days of DOS 
because linked lists avoided the "keep it together" problem with 
container chunks. Pointer arrays were (and still are) fantastic because 
you could declare a pointer array of say 1000 at compile time and only 
store the pointer to some allocated object.

read up on the alloc family here:

https://www.geeksforgeeks.org/dynamic-memory-allocation-in-c-using-malloc-calloc-free-and-realloc/

I hate pointing anyone to stackoverflow because so much of what is on 
there is wrong, but . . . this isn't a too horrible discussion.

https://stackoverflow.com/questions/2204176/how-to-initialise-memory-with-new-operator-in-c

Probably better discussion here:

https://www.simplilearn.com/tutorials/cpp-tutorial/cpp-memory-management

Anyway, once we started getting application frameworks and template 
libraries, arrays of pointers got way better.

https://www.geeksforgeeks.org/initialize-a-vector-in-cpp-different-ways/

vector<type> vector_name(//size, default_value//);

You use a known bogus value to initialize the entire vector indicating 
unused pointers. Whenever you nuked something you set that entry to the 
bogus value.

On 1's complement machines it was common to use -0. On 2's complement 
machines many developers shot themselves in the foot using -1 instead of 
ULONG_MAX.

If you want to really understand things (or have trouble falling asleep) 
study PAGE_SIZE. On VAX and many early computers (after disk drives 
invented) it was 512 bytes because that was the size of a disk block. 
This enabled Page Files and virtual memory. When the Alpha and 64-bit 
world happened PAGE_SIZE was configured by the system manager and set to 
a number of Pagelets. What was a Pagelet? 512 bytes. Usually PAGE_SIZE 
was around 8K.

Each OS with some kind of virtual memory or swap file (they are 
different) has a minimum memory allocation unit for each process and it 
is tied to the minimum unit of their disk. In the x86 computer world, if 
aging memory serves, when you look at the disks from command line you 
will see the term "cluster size" which is the minimum number of disk 
blocks you can allocate (or I/O) at once.

On 10/28/24 08:18, John Selverian wrote:
> I still don’t understand why Windows append is so much slower than on Linux & OSX...I guess it's one of life mysteries...

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593  (cell)
https://theminimumyouneedtoknow.com
https://infiniteexposure.net
https://johnsmith-book.com

_______________________________________________
Foxgui-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/foxgui-users