Jochem and tedd discussed:
Isn't assigned memory just blocks of reserved addresses for the
requesters use? It shouldn't make any difference where, or how
much, a block of memory is. To move from a field in a record to
another field is just following memory addresses from one field to
another field in each record. It doesn't make any difference if the
jump is 1 byte of a million bytes, it's just an address.
right but fixed sized jumps are best (base 2 anyone?) - i.e. no varchars.
also experiment with table types in mysql - maybe use a 'temporary' HEAP
or MEMORY table to process and then select back into the 'permanent'
table when your done with the heavy lifting.
I still don't see it. Maybe thi is something like optimizing hash
table's maximum numbers tied to a prime number type of thing, but
fixed jumps in a linked list has no benefit over variable jumps
regardless of what number system you use.
how about easy to calculate (i.e. + N) memblock positions in physical
memory?
Why would anyone/anything want to do that? It isn't necessary to
calculate memblock positions in physical or whatever memory (besides
older disk sectors).
The distribution of memory blocks residing in memory is known only to
the memory manager or whatever you want to call it. But, access to
"related" pieces of memory, such as records found in a dB, are only
connected by a linked list of some type. Memory isn't assigned by
some formula or calculation. It is assigned by request and that
request is granted by a memory manager.
Now, one way to test our differences in memory management claims
would be to acquire x chunks of memory in fixed sizes and acquire x
chunks of memory in variable amounts and then search the two memory
list. If so, I can tell you right now that the search times would be
identical in both cases.
If there is something I don't understand here, please elaborate.
tedd
--
--------------------------------------------------------------------------------
http://sperling.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php