SUMIF 等函式,在整列作為引數時,是否存在效率問題?

時間 2021-06-09 08:36:59

1樓:

效能差別挺大的。

我有幾個表,使用的是【INDEX+MATCH+SMALL+IF】那個經典提取不同值公式+【可變可搜尋下拉列表】組合,多層套用,輔助列大概長這樣——

實際用的地方大概長這樣——

考慮到源資料量的不斷擴充,基於一次到位後期不累原則,開始使用的是整列選取,後果就是——

每操作任意乙個單元格(包括該工作簿檔案開啟狀態下操作其他工作簿的單元格)都要等至少幾十秒,工作體驗約等於騎一輛兒童自行車從北京到廣州。

後來把【可變可搜素下拉列表】改為了【可變下拉列表】,去掉搜尋功能,雖然卡頓沒之前那麼誇張,但每次操作單元格也有明顯遲滯感——

最終無奈把A:A改為了A1:A16384,然後就沒有遲滯感了。

用了一段時間指定區域,實在感覺憋屈,雖然源資料量增長沒那麼快吧,可終究有隱患,EXCEL人絕不能屈服!

於是在某次洗澡時(實際情況不記得了/劇情需要)忽然想到了【可變下拉列表】使用的【OFFSET+COUNTA】,既然可以做可變下拉列表,那為什麼不能用來判斷資料區域範圍呢?說幹就幹——

G1=COUNT(審圖清單!A:A)+31

分開只是為了檢查結果,反正這一整個工作表都是輔助列,無所謂排版

=INDEX(OFFSET($A$1,0,0,$G$1-ROW($A$1)+1,1),SMALL(IF(OFFSET($A$1,0,0,$G$1-ROW($A$1)+1,1)<>"",ROW(OFFSET($A$1,0,0,$G$1-ROW($A$1)+1,1)),$G$1),ROW()))&""

好了舒服了,這下沒有遲滯感了。

選全列後公式會遍歷套用到每個單元格,特別遇上SMALL()這模擬較大小的那絕對是噩夢。而我使用COUNT()這個簡單函式來套全列,後續複雜計算只需要在小範圍內執行,速度就上來了。

(這條已經跟提問無直接關係了,但是可以發現微軟爸爸從底層上設計函式可以提高很多效率)

後來我又知道了乙個神奇海螺(劃掉)……神奇函式,UNIQUE()

效果嘛——

當然,當時髮圈時用的還是動態範圍,可是我幾分鐘前測試了下全列取值,響應速度也能接受,備註掉這條公式和使用這條公式時整個軟體的響應速度並沒有明顯區別。

2樓:一生有你

呵呵,問題提的很好,我也曾經有過這樣的疑問,還生怕整列作為引數時Excel吃不消會有效能問題,心裡總有些擔憂,特別是當整列資料量很大的時候。(是不是有點蛋操心)

期待專家解答。

C 內聯函式和constexpr函式可以在程式中定義不止一次,這個一般用在什麼時候?

楊個毛 用來讓你製造一堆weak symbol,然後一不小心試圖把兩個不同libstdc 版本的.o檔案鏈結在一起的時候死得不明不白的。 Pluto Hades 你們為什麼搞這麼複雜?inline關鍵字是在宣告的時候用的,不是在定義的時候寫。題主你把inline和函式體挪到頭檔案再試一次。另外,C ...

printf 等系統庫函式是如何實現的?

張想 windows上有個標準裝置,std,printf在根源上是,通過windows API GetStdHandle 來得到這個裝置,然後通過WriteFile API來寫這個裝置。printf也好,putchar 也好,他只是向乙個stdout緩衝區來寫資料 這是裝置系統無關的 這是C語言做的...

在不同的gcc版本中,函式傳入指標,在函式執行結束後列印指標指向值會有不同嗎?

SPeak int plusOne int digits int digitsSize int returnSize c int plusOne int digits int digitsSize int returnSize cpp int plusOne int digits int digit...