LB Booster
« I'm glad to see LBBooster still progressing »
Welcome Guest. Please Login or Register. Apr 1st, 2018, 04:55am
ATTENTION MEMBERS: Conforums will be closing it doors and discontinuing its service on April 15, 2018. We apologize Conforums does not have any export functions to migrate data. Ad-Free has been deactivated. Outstanding Ad-Free credits will be reimbursed to respective payment methods.
Thank you Conforums members.
Speed up Liberty BASIC programs by up to ten times!
Compile Liberty BASIC programs to compact, standalone executables!
Overcome many of Liberty BASIC's bugs and limitations!
Re: I'm glad to see LBBooster still progressing
« Reply #2 on: Nov 23rd, 2013, 3:34pm »
Oh, really? That's fantastic, 'cause I alwaysDIM my arrays at "1" and then REDIM them on the fly to the exact size I need. Assuming that this is not the way in which LibertyBASIC operates (and I am), this would probably be a point to make on your LBB info page. It's good to know.
So, what are the practical limits to LB Booster's environmental space? Through judicial use of file-splitting and large arrays, would it be possible to hold GigaBytes of data? Not that I would wish to, mind you. I'm just curious as to the outer limitations of LBB's capabilities.
So, what are the practical limits to LB Booster's environmental space?
It's a 32-bit application, so it has access to 2 Gbytes of user address space. How much of this could actually be allocated to arrays depends on two factors: how much RAM is available, and how fragmented is the address space.
On your PC, with 8 Gbytes of RAM, fragmentation will probably be the limiting factor. Unfortunately it's hard to predict that, because it will tend to vary from system to system.
On this particular PC, the biggest numeric array I could create was about 100 million elements (i.e. about 1 Gbyte of storage; LBB uses 80-bit floats), but your mileage may vary.
Logged
