Wast of memory
Wast of memory
I wrote a little calender-Tool (display a week, show the day in the systray and popup on a specific time).
Only one big problem: A small 75KB-Tool with not many things need about 2.5-3.8 MB!
http://caosandkin.bei.t-online.de/pureb ... lender.zip
Sorry, complete german an it is not really compileable with IDE (IDE should take cut.termin.pb). The programm need the termin.res as resource.
Only one big problem: A small 75KB-Tool with not many things need about 2.5-3.8 MB!
http://caosandkin.bei.t-online.de/pureb ... lender.zip
Sorry, complete german an it is not really compileable with IDE (IDE should take cut.termin.pb). The programm need the termin.res as resource.
btw:
need over 2 MB RAM.
Code: Select all
If OpenWindow(1,0,0,200,200,#PB_Window_ScreenCentered|#PB_Window_SystemMenu,"Test")
If CreateGadgetList(WindowID())
Repeat
Event=WaitWindowEvent()
Until Event=#PB_Event_CloseWindow
EndIf
EndIfI don't think that's the source of the problem. This code alone uses nearly 3mb:
Maybe that's a collection of PB's pre-allocated buffers? strings, etc?
Code: Select all
repeat
forever-
DominiqueB
- Enthusiast

- Posts: 103
- Joined: Fri Apr 25, 2003 4:00 pm
- Location: France
Hello GPI
Where could one get the .tes needed, and the ResFreeIcon() and others functions to be able to compile your code ?
Thank's for sharing.
Dominique
Thank's for sharing.
Dominique
Dominique
Windows 10 64bits. Pure basic 32bits
Windows 10 64bits. Pure basic 32bits
GPI,
That's a nice program!
I noticed a couple of English mistakes, if you're interested:
Calendar not Calender
Tuesday should be abbreviated "Tu", not "Th"
Sunday should be abbreviated "Su", not "So"
September, not Septembers
October, not Octobers
November is OK!
December, not Decembers
Regards,
Eric
That's a nice program!
I noticed a couple of English mistakes, if you're interested:
Calendar not Calender
Tuesday should be abbreviated "Tu", not "Th"
Sunday should be abbreviated "Su", not "So"
September, not Septembers
October, not Octobers
November is OK!
December, not Decembers
Regards,
Eric
What are you talking about??Kris_a wrote:I don't think that's the source of the problem. This code alone uses nearly 3mb:
Maybe that's a collection of PB's pre-allocated buffers? strings, etc?Code: Select all
repeat forever
572 Kb memory usage, nothing more.
(1.4 mb with debugger)
quidquid Latine dictum sit altum videtur
-
Num3
- PureBasic Expert

- Posts: 2812
- Joined: Fri Apr 25, 2003 4:51 pm
- Location: Portugal, Lisbon
- Contact:
Ok, create a window with a gadget...freak wrote:What are you talking about??
572 Kb memory usage, nothing more.
(1.4 mb with debugger)
Minimize it a few times (memory should drop a lot ~200Kb average), then bring it up again and memory usage will about 1/3 of what it consumed when it first started, and after a bit of usage back to a few MB... 8O
I've made several applications in Purebasic, and here's the memory consuption of each (just opened and doing nothing)
- o Pesquisa CTT
(1 window, 3 gadgets, 1 database - 73Kb EXE)
First Run - 3.6Mb
After minimizing and restoring - 528Kb
o Husse Gest
(1 Window, 30 gadgets, 3 databases - 23Kb EXE)
First Run - 2.8Mb
After minimizing and restoring - 725Kb
o Rendas 2003
(1 Window,83 gadgets, 1 database - 36Kb EXE)
First Run - 3.6Mb
After minimizing and restoring - 432Kb
o IPGest (Just GUI, no code yet!!!)
(1 Window, 15 gadgets - 15Kb EXE)
First Run - 2.4Mb
After minimizing and restoring - 760Kb
Take SoftIce
Take SoftICE and open up the operating system and take a look at what's happening on Windows XP. The gdi32.dll, kernel32.dll, user32.dll, advapi32.dll, ntdll.dll, ole32.dll, shell32.dll, etc.. are copied into a protected "sandbox" of memory to be granted permission to be used, unlike Windows 98 where the same dlls the operating system uses are the same dlls any program running in memory uses. This makes the operating system virtually "crash proof", and protects software by essentially breaking programs like SoftIce.
Windows libraries are all shared between all programs, and are loaded when needed by the first program.
This should means that the first program on your computer will see memory go up by a lot as windows loads everything. However, the subsequent programs will share these resources and there won't be a problem.
So, what happens when you load something else first, then your PB executable? Is it following this pattern?
This should means that the first program on your computer will see memory go up by a lot as windows loads everything. However, the subsequent programs will share these resources and there won't be a problem.
So, what happens when you load something else first, then your PB executable? Is it following this pattern?
GedB: are you sure ? That is not good old AmigaOS (waiting for 4.0)
. Windows DLLs aren't shared by default, it means each program that opens a DLL will have ITS OWN instance of that DLL. That can be good and bad (not good for memory). Actually it's also possible to write shared DLLs, but I am not sure system DLLs like kernel32,user32, etc... are shared.


