FROM : Alex Rice
DATE : Tue Nov 19 19:16:11 2002
On Monday, November 18, 2002, at 04:23 PM, David Remahl wrote:
>> My point (usability issues ignored, for the time being), is that you
>> can use
>> what ever storage and allocation method you want. For example, you
>> could use a
>> linked list in C code, for which you are responsible of all memory
>> management.
>> The actual allocation is not a siginifiant bottle neck in most cases,
>> but
>> retain/release may be. Many else have pointed this out.
>>
>> In the data source, you then provide the information required by the
>> control.
>> That is seldom more than 200 cells at a time, and that happens in a
>> quite
>> short time, and is not dependant of the size of the underlying data
>> set.
>>
This has been an interesting through and I just want to recap what has
been said, and point out that one of Rixstep's main questions hasn't
been answered.
1) Does Unix/BSD/OS X have the equivalent functionality of Win32's
HeapCreate, HeapAlloc, HeapDestroy? If no, what is the C programming
method used instead?
1a) Rixstep thinks that the absence of these functions is going to
prevent him from writing a NSTableDataSource that will be as quick as
the Windows implementation of a tabular browser for many K's of rows.
Is this as much of a bummer as he thinks?
1b) Maybe this is a question for asking on Usenet in comp.lang.c or
something? This just occurred to me: it's likely the answer can be
found in the source to the WINE project which is basically an
open-source Win32 runtime for Linux.
--
2) The MVC pattern and NSTableDataSource protocol are a help not a
hinderance and don't prevent Rixstep from writing the backend in as
gnarly C code as he wants to. :-)
3) The NSTableView, and most everything in Cocoa, buffers the display
so one generally doesn't need to worry about locking for redraws like
one would on Win32.
4) NSTableView itself is doing nothing to hurt performance. Because of
the MVC pattern, the NSTableView ONLY sees objects for which is will
actually display. It doesn't do anything to those objects which is
going to slow you down. Any bottleneck is in the NSTableDataSource
implementation.
HTH
Alex Rice <<email_removed>>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
DATE : Tue Nov 19 19:16:11 2002
On Monday, November 18, 2002, at 04:23 PM, David Remahl wrote:
>> My point (usability issues ignored, for the time being), is that you
>> can use
>> what ever storage and allocation method you want. For example, you
>> could use a
>> linked list in C code, for which you are responsible of all memory
>> management.
>> The actual allocation is not a siginifiant bottle neck in most cases,
>> but
>> retain/release may be. Many else have pointed this out.
>>
>> In the data source, you then provide the information required by the
>> control.
>> That is seldom more than 200 cells at a time, and that happens in a
>> quite
>> short time, and is not dependant of the size of the underlying data
>> set.
>>
This has been an interesting through and I just want to recap what has
been said, and point out that one of Rixstep's main questions hasn't
been answered.
1) Does Unix/BSD/OS X have the equivalent functionality of Win32's
HeapCreate, HeapAlloc, HeapDestroy? If no, what is the C programming
method used instead?
1a) Rixstep thinks that the absence of these functions is going to
prevent him from writing a NSTableDataSource that will be as quick as
the Windows implementation of a tabular browser for many K's of rows.
Is this as much of a bummer as he thinks?
1b) Maybe this is a question for asking on Usenet in comp.lang.c or
something? This just occurred to me: it's likely the answer can be
found in the source to the WINE project which is basically an
open-source Win32 runtime for Linux.
--
2) The MVC pattern and NSTableDataSource protocol are a help not a
hinderance and don't prevent Rixstep from writing the backend in as
gnarly C code as he wants to. :-)
3) The NSTableView, and most everything in Cocoa, buffers the display
so one generally doesn't need to worry about locking for redraws like
one would on Win32.
4) NSTableView itself is doing nothing to hurt performance. Because of
the MVC pattern, the NSTableView ONLY sees objects for which is will
actually display. It doesn't do anything to those objects which is
going to slow you down. Any bottleneck is in the NSTableDataSource
implementation.
HTH
Alex Rice <<email_removed>>
Mindlube Software
http://mindlube.com/
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
| Related mails | Author | Date |
|---|---|---|
| Rixstep | Nov 18, 06:28 | |
| Alex Rice | Nov 18, 08:54 | |
| Alex Rice | Nov 18, 09:11 | |
| Andreas Mayer | Nov 18, 10:28 | |
| <rixstep000 | Nov 18, 13:43 | |
| <rixstep000 | Nov 18, 14:10 | |
| <rixstep000 | Nov 18, 16:27 | |
| Alex Rice | Nov 18, 20:14 | |
| Andreas Mayer | Nov 18, 22:07 | |
| j o a r | Nov 18, 22:49 | |
| j o a r | Nov 18, 23:34 | |
| David Remahl | Nov 19, 00:23 | |
| Terrence Asselin | Nov 19, 01:39 | |
| Kevin Elliott | Nov 19, 18:27 | |
| Alex Rice | Nov 19, 19:16 | |
| Clark S. Cox III | Nov 19, 22:20 | |
| Rosyna | Nov 20, 07:25 |






Cocoa mail archive

