Thanks, you are correct. Very helpful. -- Howard.
On 24 March 2016 at 11:20, Kate Stone <k8st...@apple.com> wrote: > You’re almost certainly seeing side effects of not keeping the instance of > TestClass alive long enough for the unsafe pointer to still refer to an > allocated malloc block. A quick REPL session illustrates this fact: > > 1> class TestClass { > 2. let a = 0 > 3. let b: Int? = nil > 4. } > 5> import Foundation > 6> malloc_size(unsafeAddressOf(TestClass())) > $R0: Int = 0 > 7> let x = TestClass() > x: TestClass = { > a = 0 > b = nil > } > 8> malloc_size(unsafeAddressOf(x)) > $R1: Int = 48 > > On line 6 the result of the TestClass() expression is being used only to > call unsafeAddressOf, and then it’s being freed before the call to > malloc_size. On line 8 the variable x is retaining the instance so the > malloc’ed region can be measured. > > Of course all of this relies on the implementation assumption that > allocated objects go on malloc’s heap and is subject to implementation > details about object layout. So while this may be instructive now it’s > certainly no guarantee of how things will work in the future. > > Kate Stone k8st...@apple.com > Xcode Low Level Tools > > On Mar 23, 2016, at 5:13 PM, Howard Lovatt <howard.lov...@gmail.com> > wrote: > > @Kate, > > I don't seem to be able to get `malloc_...` to work. EG: > > class TestClass { > let a = 0 > let b: Int? = nil > } > @_silgen_name("swift_class_getInstanceExtents") func > swift_class_getInstanceExtents(theClass: AnyClass) -> (negative: UInt, > positive: UInt) > print("swift_class_getInstanceExtents = > \(swift_class_getInstanceExtents(TestClass))") > let requiredSize = malloc_size(unsafeAddressOf(TestClass())) > print("malloc_size = \(requiredSize)") > print("malloc_good_size = \(malloc_good_size(requiredSize))") > > > Prints: > > swift_class_getInstanceExtents = (0, 33) > malloc_size = 0 > malloc_good_size = 16 > > > The `swift_class_getInstanceExtents` seems correct to me: 16 bytes for > class overhead + 16 bytes for `a` and `b` + 1 byte because `b` is an > optional = 33 bytes. > > Not sure what `malloc_...` is giving? > > -- Howard. > > On 24 March 2016 at 10:39, Kate Stone <k8st...@apple.com> wrote: > >> I definitely concur that tools like Instruments are the best way to >> understand the impact of decisions on memory across the board. For >> fine-grained inquiries about memory use you can also rely on malloc family >> functions to make inquiries: >> >> let required_size = malloc_size(unsafeAddressOf(*object_reference*)) >> let actual_size = malloc_good_size(required_size) >> >> >> Kate Stone k8st...@apple.com >> Xcode Low Level Tools >> >> On Mar 23, 2016, at 3:59 PM, Howard Lovatt via swift-users < >> swift-users@swift.org> wrote: >> >> Thanks, I will give that a try >> >> -- Howard. >> >> On 24 March 2016 at 03:17, Jens Alfke <j...@mooseyard.com> wrote: >> >>> >>> On Mar 22, 2016, at 11:04 PM, Howard Lovatt via swift-users < >>> swift-users@swift.org> wrote: >>> >>> I am writing custom collection classes and trying to assess which one is >>> better, both in terms of performance and memory usage. Won't be used in >>> 'real' code, just to guide development. >>> >>> >>> You might consider using heap profiling tools too, like (on Mac OS) the >>> Instruments app or the `heap` command-line tool. If you use these while >>> running a benchmark app using your API, it can show you how much total heap >>> space gets used. >>> >>> Actual heap usage can differ from the raw “sizeof” a data type, since >>> allocators will often round up block sizes or return a somewhat larger >>> block than necessary. Heap fragmentation can also increase memory usage >>> beyond what you’d expect, and different allocation patterns can affect >>> fragmentation. >>> >>> —Jens >>> >> >> _______________________________________________ >> swift-users mailing list >> swift-users@swift.org >> https://lists.swift.org/mailman/listinfo/swift-users >> >> >> > >
_______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users