Doriano Blengino wrote: > > Probably there is some bug here, but anyway I would use some other mean > to achieve the goal. > ... > If you really have 65536*65536 cells, all alive together, you could use > a binary file on disk. Disk caching will speed up things, perhaps better > than fake ram swapped in/out from disk. > > If you don't have all the cells live together, you could use an > association, and only keep in ram the cell along with its "coordinates". > ... > If you insist on the ram approach, then a static array would consume > less memory, if it is still supported. >
Good advice. I think I'm going to be forced to use a binary file because all the data is interdependent. I'm basically applying the "diamond square" algorithm to the cells (which reminds me I need 65537x65537 shorts, not 65536x65536). Hopefully, if that was a bug, it will get ironed out because it wasn't handled terribly gracefully by GAMBAS. ----- Kevin Fishburne, Eight Virtues www: http://sales.eightvirtues.com http://sales.eightvirtues.com e-mail: mailto:[email protected] [email protected] phone: (770) 853-6271 -- View this message in context: http://old.nabble.com/array-size-limitations-relative-to-available-RAM-and-swap-space-tp27268616p27278998.html Sent from the gambas-user mailing list archive at Nabble.com. ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Gambas-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/gambas-user
