Re: ABI Compatibility (was Re: Installation woes for the average user...)

[Riccardo Mottola]

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