Mattias Gaertner wrote:
Well, if you use objects, then you get even more mem overhead ... :)
I was thinking about that too. Then, IIRC, I read that object overhead
is a one-time allocation of class tables and such. Of course, you might
have some extra overhead inherited from TObject (Clas
Mattias Gaertner wrote:
If the linked list item contains the whole data, then you are either not
talking of the generic list this thread is about, or you use templates. In
the later case a TList will also use templates and the 'payload' is the
same.
That's true of records, sure. Someone coul
Mattias Gaertner wrote:
Plus some bytes for the memory manager for each mem block. Typically 8.
Forgot about that, sorry. In any case, the math still works. I'll
explain.
In this case, 10,000 entries occupy 80,008 bytes
(80,000 + 4 for pointer to First + 4 for pointer to Last),
Mattias Gaertner wrote:
Your trick will only give a constant factor on growing/shrinking the list
memory, gives an extra O(n) factor for sorting a TList, the caching costs
time, and the memory usage will also grow.
Just saw this last statement. The memory usage is very comparable to
TLi
Michael Van Canneyt wrote:
People that have large lists know this and take care of it.
What is more, I think that 1 large memory block (an array) is much more
efficient memory wise than many small blocks.
This is true in some cases; VMs and scripting engines (such as
SpiderMonkey) us
Micha Nelissen wrote:
Hi,
I've been thinking about adding a linked list implementation to either TList
or TFPList. The basic problem to that is of course
1) space overhead of linked list is quite large
2) Index[..] will be O(N)
For (1) I was thinking about making a linked list of an array of i
In response to Tomas Hajny:
I wasn't entirely certain about the use of EOF_CTRLZ, but since it's a conditional compile, and the patch is in an include, I felt it better to use it than ignore it :)
I agree regarding ReadNumeric. That one will need some work.
Thanks,
Sterling
Your messag
In reply to Thomas Schatzl:
Another optimization for your patch is to set a var to length(s) at the beginning of the proc, and use the var instead. It's called often enough that a little time could be shaved off.Post your free ad now! Yahoo! Canada Personals__
In response to Tomas Hajny:
I'd certainly be willing to give it a try. Granted, I only have Windows XP, but if I'm careful it should be a smooth transition. No promises on a timeline :)
Another problem with Windows (not sure about other OSs) is in bug 2084. (Use the second example in the de
This patch adds recognition for hex to Val().
SterlingPost your free ad now! Yahoo! Canada PersonalsIndex: sstrings.inc
===
RCS file: /FPC/CVS/fpc/rtl/inc/sstrings.inc,v
retrieving revision 1.35
diff -w -b -i -u -p -1 -0 -r1.35 sstri
This is my first shot, so be gentle :-)
The patch assumes FP wants sufficient compatibility with BP 7. If so, it
fixes two problems; if not, at least it was a fun exercise.
First, BP ignores non-numeric characters when a ReadLn is called with an
integer parameter. To fix this, I changed ReadNume
Turns out the CRT unit in OS/2 -- which, by my searches, uses #13#10 as CRLF -- was recognizing #13 alone as CRLF. #10 was completed ignored.
SterlingPost your free ad now! Yahoo! Canada PersonalsIndex: crt.pas
===
RCS file: /FPC/C
(My ISP's mail server is blacklisted, so sending this from Yahoo. Ugh.)
This is my first shot, so be gentle :-)
The patch assumes FP wants compatibility with BP 7. If so, it fixes two problems; if not, at least it was a fun exercise.
First, BP ignores non-numeric characters when a ReadLn is
13 matches
Mail list logo
