2010-09-14 18 views
11

Tôi nhận ra rằng những gì được tính là tối ưu hóa sớm có một thành phần chủ quan, nhưng đây là một câu hỏi thực tiễn hoặc thực hành tốt nhất.Sử dụng Structs trong Objective-C (cho iOS): Tối ưu hóa sớm?

Khi lập trình cho iOS, tôi có nên sử dụng struct và typedefs nơi đối tượng không có "hành vi" (phương pháp, về cơ bản) không? Cảm giác của tôi là cú pháp struct hơi lạ đối với một người không phải C, nhưng nó phải là CÁCH thấp hơn. Sau đó, một lần nữa, thử nghiệm một số trường hợp với 50K NSObject trường hợp, nó không có vẻ xấu (tương đối, tôi biết). Tôi có nên "làm quen với nó" (sử dụng cấu trúc nếu có thể) hoặc là NSObject trường hợp được, trừ khi tôi có vấn đề về hiệu năng?

Trường hợp điển hình sẽ là lớp có hai biến thành viên int. Tôi đã đọc rằng sử dụng một cấu trúc để giữ hai trường hợp NSString (hoặc bất kỳ lớp con NSObject) là một ý tưởng tồi.

+1

Tôi muốn đọc nơi để nói rằng sử dụng cấu trúc để giữ lớp NSObject là một ý tưởng tồi, chỉ để học – vodkhang

+0

Đó là một ý tưởng tồi vì, um, bạn sẽ duy trì 'giữ lại' và' phát hành' ở đâu? – Yuji

+0

@vodkhang, một nơi nào đó ở đây http://stackoverflow.com/questions/1064500/pass-and-access-structures-using-objective-c –

Trả lời

10

Đi với các đối tượng thông thường cho đến khi bạn nhấn nút cổ chai hiệu suất có thể đo lường. Tôi đã sử dụng mã cấp cao ngay cả trong các vòng trò chơi chặt chẽ mà không gặp sự cố - nhắn tin, các lớp thu thập, các nhóm tự động phát, không có vấn đề gì.

+0

Cảm ơn, đó là quyết định của tôi tối qua lúc 3 giờ sáng. Chỉ muốn kiểm tra xem tôi có phát điên không. –

+1

Đó là một quyết định quan trọng và bạn nên nghĩ về nó một chút. Nhưng hiệu suất của phần cứng ngày nay - ngay cả trên thiết bị di động, cấp thấp hơn - thật đáng kinh ngạc và khiến cho vấn đề này gần như không có trí tuệ. – zoul

+1

Có. Đó là một thế giới thực sự kỳ lạ, trong đó một số người đang làm việc một mức trừu tượng UP (MonoTouch) hoặc, ở các thế giới khác, MANY mức trừu tượng hóa cao hơn (Groovy trong JVM) với các hình phạt hiệu suất chấp nhận được, và những người khác nhấn mạnh vào việc tối ưu hóa mọi thứ nhiều nhất có thể. Cảm ơn bạn đã lưu ý về "vòng trò chơi chặt chẽ", điều đó chắc chắn giúp tôi hiểu những gì có thể. –

11

Một đối tượng C mục tiêu có lưu trữ gần như giống như một cấu trúc, ngoại trừ nó là 4 byte (8 byte trên 64 bit) lớn hơn. Đó là nó - chỉ cần một con trỏ vào một nơi mà thời gian chạy giữ tất cả các thông tin về lớp.

Nếu bạn bị chặt chẽ trên bộ nhớ, sau đó mất 4 byte, nhưng thường chỉ dành cho số lượng lớn đối tượng: 50.000 Nsobjects so với cấu trúc chỉ 200k - bạn nhận được rất nhiều thứ cho 200k đó. Đối với một triệu đối tượng, chi phí sẽ tăng lên trên iPhone.

Nếu bạn muốn chuyển các mục sang OpenGL hoặc cần một mảng c cho các mục đích khác, thì một tùy chọn khác là tạo MỘT NSObject có con trỏ malloc'ed tới tất cả 50.000 số nguyên. Sau đó, bộ nhớ c mục tiêu trên đầu là ~ 0, và bạn có thể gói gọn tất cả các công cụ malloc và free() khó chịu vào bên trong của một tệp .m.

+0

Hummm, tôi nghĩ rằng đó không chỉ là vấn đề với trí nhớ. Nó cũng là về tham chiếu. Tôi nhớ rằng nếu bạn sử dụng struct, thì bạn không cần phải truy cập vào bộ nhớ heap object, chỉ truy cập stack, nhanh hơn nhiều :) (kiến thức của tôi là từ C#, không chắc chắn về obj-C) – vodkhang

+1

+1 để gói những thứ cấp thấp khi bạn thực sự cần nó. – zoul

+1

@vodkhang: tốc độ không quan trọng, trừ khi bạn muốn mã hóa một cái gì đó giống như một động cơ hạt với hàng ngàn đối tượng cá nhân được tính toán lại ở tốc độ 30 khung hình/giây. – zoul

3

Đối với tôi, tôi muốn sử dụng các đối tượng thông thường vì bạn có thể dễ dàng thực hiện công việc đối tượng với nó như giữ lại, giải phóng, tự động phát hành. Tôi chỉ thấy khá ít cấu trúc trong Cocoa Framework như CGSize, CGRect và CGPoint. Tôi nghĩ lý do là họ đang được sử dụng rất nhiều

+0

điểm tốt về ca cao –

1

Tôi tin rằng nên sử dụng cấu trúc đặc biệt nếu bạn đang xử lý khung dựa trên C, cho phép OpenGL, CoreGraphics, CoreText đặc biệt yêu cầu một cặp vợ chồng/ba của ints, tăng gấp đôi, ký tự, vv (Nếu chúng chưa được thực hiện trong một số khung của Apple: CGRect, CGPoint, CTRect, NSRange, vv ...) C sẽ phát và trông đẹp hơn với các công cụ C khác.

Tôi không nghĩ mình sẽ viết một lớp con của NSObject chứa một vài int. Nó gần như vô lý. lol.

14

Struct s với NSObject trường hợp trong đó chắc chắn là một ý tưởng tồi. Bạn cần -init-dealloc để xử lý số lần lưu giữ chính xác. Viết retainreleases từ phía người gọi chỉ là điên. Nó sẽ không bao giờ trả hết.

Struct s với hai int hoặc bốn double s là các trường hợp đường biên. Bản thân khung Cocoa thực hiện NSRect, NSPoint vv như một cấu trúc. Nhưng thực tế đó đã nhầm lẫn rất nhiều và rất nhiều người mới đến. Thành thật mà nói, ngay cả sự khác biệt giữa các loại nguyên thủy và các loại đối tượng lẫn lộn chúng.Nó trở nên khó hiểu với tôi khi bạn có struct s như thuộc tính của một đối tượng: bạn không thể làm

object.frame.origin.x=10; 

Nếu bạn bắt đầu thực hiện của riêng bạn struct s, bạn cần phải nhớ là đó. Đó lại là một rắc rối. Tôi nghĩ lý do tại sao họ (NSRect, v.v.) là struct s về cơ bản là lịch sử.

Tôi muốn tạo mọi vật thể. Và sử dụng bộ sưu tập rác nếu có.

Và đừng hỏi mọi người xem điều gì đó có đáng được tối ưu hóa hay không. Tự mình đo bằng dụng cụ hoặc bất kỳ thứ gì. Tùy thuộc vào môi trường (ppc vs intel, OS X và iOS, iPad và iPhone) một cách nhanh hơn trong một hệ thống trước đó có thể chậm hơn trong một hệ thống mới.

5

Tôi thấy không có vấn đề gì với việc sử dụng cấu trúc để giữ số lượng nhỏ các loại nguyên thủy (tức là đối tượng không) mà không có hành vi bắt buộc. Đã có một số ví dụ về điều này trong các khuôn khổ Ca cao (ví dụ: CGRect, CGSize, CGPoint, NSRange).

Không sử dụng cấu trúc để giữ đối tượng Objective-C. Nó phức tạp quản lý bộ nhớ trong môi trường tính tham chiếu và có thể phá vỡ nó hoàn toàn trong môi trường GC.

+0

Tôi nghĩ rằng tôi đã trả lời câu hỏi một cách hoàn hảo. Bạn nói "tôi có nên quen với nó không?" Câu trả lời là có, bởi vì, đối với các cấu trúc nhỏ, nó đã khá phổ biến. – JeremyP