Hi, David Chisnall wrote: > On 7 Mar 2009, at 08:30, Riccardo Mottola wrote: > >> - I do not want any additional runtime overhead. Performance needs to be >> maximum. Always. > > Don't use Objective-C then. The language compromises performance for > flexibility all of the time. How much in GNUstep is CPU-bound? Most > of the bottlenecks I see are network and I/O-related. I disagree, but apparently you never tried to run GNUstep on something else than a desktop or workstation. Also: if others do not care about performance, why shouldn't we? > > No overhead is not possible. All of the proposed solutions add overhead: > You forget one solution: no solution because the problem is not blocking. With correct so-name changes, old applications will run against old binaries, new one will link and run against new ones. It works already. The problem we have mostly is while tracking SVN: in that case we get changes without the correct soname change. But this should be a nuisance only for developers, not for users: thsy should track release.
If we compare to other projects like glib2, gtk2: fine-grained packages like debian will give you udpates only when necessary (but this can be done for gnustep too, without problems). On system where you build, like NetBSD with pkgsrc or gentoo, one update trigegrs the recompilation of all packages. Just did that yesterday: update glib2? Be prepared to recompile up to your browser. Thus, don't break what works. But we shall be careful with new release, correct minor and major releases, etc etc. > If you add extra, unused, space in objects, you bloat memory usage and > (much worse) data cache usage and trigger more cache misses and more > paging on memory-constrained systems. Yes, this appears to me the "least hurting" path. But I laready dislike. If we really need, this should be the road. > > If you make private ivars into a structure and make a pointer to this > an ivar, you add an extra malloc for every +alloc (expensive) and you > add an extra load for ever ivar access. That is an abomination. --Riccardo _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev