Re: slow startup on windows
[email protected] Fri, 25 Oct 2024 13:16:12 -0500
| Newsgroups | gmane.comp.lib.fox-toolkit.user |
|---|---|
| Message-ID | <[email protected]> |
On 2024-10-25 10:43, John Selverian wrote:
> The program is a database where everything is stored as strings,
> they're all wrapped in classes, so its actually stored as a 4D
> array of classes. When it's running it takes 235 MB in memory.
>
> The strings are not displayed in the UI.
>
> I timed this:
>
> FXString* tmp;
> long num = 500000;
> //long num = 5000000;
> for (long i = 0; i < num; i++)
> {
> tmp = new FXString("test string");
> delete tmp;
> }
>
> For num = 500,000 it's somewhere around 1 second, for num =
> 5,000,000 takes about 3 seconds. I also used a longer string
> ("test string test string test string test string test string
> test string test string test string ") and saw no effect. I'm
> just timing in the debugger with a stopwatch, nothing fancy so
> the times are only approximate but clearly noticeable.
Of course, it depends on your machine, but it seems entirely
reasonable.
Debug vs. release may make significant difference. Also, make
sure target arch is set correctly [-with-arch=native optimizes
for local machine, i.e. the one the compiler is running on].
Your test is actually a-typical, you're actually doing 1,000,000
and 10,000,000 allocations. for each i, you're allocating both
the string and the string's buffer.
Also, repeatedly allocating and freeing the same size entity will
probably recycle memory, this is not the same as allocating NEW
memory 500,000 times.
A more fair test may be:
FXString strs = new FXString [num];
for (long i = 0; i < num; i++){
strs[i]="test string";
}
delete [] strs;
This will perform num+1 allocations, num for each string's buffer, and
one giant one for the array-of-strings.
FYI, time of a memory allocation is somewhat independent of the
size being allocated. Somewhat, because once the size exceeds
a certain value, the system will switch to an mmap call and do
an operating system call; for the gory details, look in the
file ~/glibc/malloc/malloc.c.
-- JVZ