2012-01-28 68 views
2

在一個具有許多不同UITableView的應用程序中,我發現自己經常使用臨時數組導入用於填充表視圖的數據,確定行數,節數,頁眉,頁腳數,等等。我想知道是否因爲這些數組需要爲表格中的每個單元格反覆創建,因此如果聲明靜態,所以不需要再次創建它們將有助於性能,因爲現在正在創建這些數組在cellForRowAtIndexPath:,numberOfRowsInSections:,numberOfSectionsInTableView:, footerForSection:`。會宣佈這麼多的靜態數組(可能包含大量的信息,比如說幾千條數據和幾百個字符串),從長遠來看,幫助還是傷害了我?我知道一個靜態數組在應用程序生命的過程中留在內存中,那麼這麼多靜態數組是否是有害的呢?假設這個過程在應用程序的整個過程中發生在4-5個視圖控制器中,我們正在討論這個數組的15-20個副本。這裏我最好的選擇是什麼?謝謝靜態變量和性能Objective-c

編輯:我正在使用保存值的​​單身人士。臨時數組的真正原因是保持代碼清潔。我可以這樣做

dataArray = [[SingletonDataController sharedSingleton] dataArray] 
    objectAtIndex:CURRENTLY_SELECTED_DATA_INDEX; 

然後

myTitleString = [dataArray objectAtIndex:keyTitleStringIndexKey]; 

,而不是分組所有到一個不可讀的語句,如:

myTitleString = [[[[SingletonDataController sharedSingleton] dataArray] 
    objectAtIndex:CURRENTLY_SELECTED_INDEX] objectAtIndex:keyTitleStringIndexKey]; 

我已經完成我自己的一些測試,比較的時間它需要在靜態初始化的情況下創建表視圖。這些結果如下:

2012-01-29 18:31:57.539 XXXXXXX[711:707] static average: 0.058798 
2012-01-29 18:31:57.543 XXXXXXX[711:707] nonstatic average: 0.058395 

正如你所看到的,靜態初始化實際上是比非靜止的要慢,但只有一秒鐘的幾萬分之一。這可能只是測量結果不準確的結果,但結果足以說服我說,這種差異足夠小而無法解決。謎團已揭開。

+0

而不是保持大量的副本可以保持包含數組或其他東西的緩存副本的單身?我不清楚爲什麼你一次又一次地創建它。它是從您的數據模型計算出來的值,而不僅僅是存儲在那裏的值? – user1118321 2012-01-28 15:56:31

+0

更新的答案與解釋 – 2012-01-28 16:10:14

回答

3

當你這樣做時,你實際上並沒有創建一個新的數組,只是獲取一個指向該數組的指針。您沒有複製實際數據。

通過保持代碼清潔,您只會失去爲指針創建內存併爲其指定值的性能。所以不,你沒有失去表現。

保持代碼清潔的想法比這個和那裏的額外指針的邊際差異要重要得多。


編輯:

,我做了兩年不如預期,這兩個選項執行非常相似的之間的一些測試。

NSMutableArray *data1 = [[NSMutableArray alloc] init]; 
NSMutableArray *data2 = [[NSMutableArray alloc] init]; 
NSArray *all = [[NSArray alloc] initWithObjects:data1,data2,nil]; 
for(int i=0;i<1000;i++) 
{ 
    [data1 addObject:[[NSNumber alloc] initWithInt:arc4random()]]; 
    [data2 addObject:[[NSNumber alloc] initWithInt:arc4random()]]; 
} 
double startTime = CACurrentMediaTime(); 
for(int i=0;i<1000;i++) 
{ 
    NSArray *get1 = [all objectAtIndex:0]; 
    NSArray *get2 = [all objectAtIndex:1]; 
    //int get1Index = arc4random() % [get1 count]; 
    //int get2Index = arc4random() % [get2 count]; 

    //NSLog(@"Object at %d: %f", get1Index, [[get1 objectAtIndex:get1Index] doubleValue]); 
    //NSLog(@"Object at %d: %f", get2Index, [[get2 objectAtIndex:get2Index] doubleValue]); 
    NSLog(@"Object at %d: %f", i, [[get1 objectAtIndex:i] doubleValue]); 
    NSLog(@"Object at %d: %f", i, [[get2 objectAtIndex:i] doubleValue]); 
} 
NSLog(@"Time with temp array:%f", CACurrentMediaTime() - startTime); 

startTime = CACurrentMediaTime(); 
for(int i=0;i<1000;i++) 
{ 
    //int get1Index = arc4random() % [[all objectAtIndex:0] count]; 
    //int get2Index = arc4random() % [[all objectAtIndex:1] count]; 

    //NSLog(@"Object at %d: %f", get1Index, [[[all objectAtIndex:0] objectAtIndex:get1Index] doubleValue]); 
    //NSLog(@"Object at %d: %f", get2Index, [[[all objectAtIndex:1] objectAtIndex:get2Index] doubleValue]); 
    NSLog(@"Object at %d: %f", i, [[[all objectAtIndex:0] objectAtIndex:i] doubleValue]); 
    NSLog(@"Object at %d: %f", i, [[[all objectAtIndex:1] objectAtIndex:i] doubleValue]); 
} 
NSLog(@"Time without temp array:%f", CACurrentMediaTime() - startTime); 
//With random access 
//2012-01-28 13:44:12.721 test[23164:f803] Time with temp array:0.924193 
//2012-01-28 13:44:13.641 test[23164:f803] Time without temp array:0.919250 
//2012-01-28 13:44:44.892 test[23191:f803] Time with temp array:0.926337 
//2012-01-28 13:44:45.812 test[23191:f803] Time without temp array:0.920447 
//With incremental access 
//2012-01-28 13:46:43.948 test[23231:f803] Time with temp array:0.935009 
//2012-01-28 13:46:44.927 test[23231:f803] Time without temp array:0.978455 
//2012-01-28 13:47:40.317 test[23254:f803] Time with temp array:1.173752 
//2012-01-28 13:47:41.307 test[23254:f803] Time without temp array:0.989263 

註釋掉部分是我用來測試的隨機訪問,我目前使用的代碼增量訪問的章節。沒有臨時數組是一個更快的分數,但並不明顯。不足以犧牲可讀性。我想這只是將它寫入一個變慢的過程,但同時,有一個未嵌入的臨時數組要快得多。如果您多次使用嵌入式陣列,則必須執行2次內存訪問,而不是1次。因此,如果您要多次使用嵌入式陣列,我認爲增益會顯着彌補使用臨時陣列的損失。

+0

感謝您的深入解答。我想我會對自己做一些測試,但看起來性能好處幾乎不明顯,可讀性可能更重要。我會發布我自己的測試結果。 – 2012-01-28 21:01:58

+0

我已經發布了我自己的測試結果。感謝您的幫助! – 2012-01-29 23:32:27