> On 18 Mar 2018, at 10:23, Fred Kiefer <[email protected]> wrote: > > > >> Am 18.03.2018 um 00:56 schrieb amon <[email protected]>: >> >> Calling internal, non-API methods is probably not a good solution >> for me. I am going to put it in the back of my mind to percolate >> awhile, but perhaps you could subclass and expand the API >> somehow. At worst you use the internal methods in the subclass >> only so that it does not spread; at best you find a way to do >> it yourself. >> >> I have not really thought about it yet, just tossing out my >> thoughts. > > Do you really think that the NSHost objects are causing serious trouble to > your application? How many different hosts is your application accessing? If > you are really worried about those, just store them in global variables and > reuse them. > But is this class really the biggest problem? Did you use the per class > statistics to see, for which kind of objects the amount increases over the > live time?
In any case, NSHost objects should normally be cached ... so whether or not they are autoreleased is most likely a red herring. If using lots of different hosts you might want to flush the cache more often. However, I agree ... an obsessive worry about this kind of thing is probably evidence of premature optimisation. Even in environments with tiny amounts of memory available autorelease is not likely to be a problem. Leaks are a problem, but using autorelease properly helps you prevent leaks. _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
