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