कुंजी के लिए डेटाटेबल में "चरित्र को अक्सर कारक पसंद किया जाता है" क्यों?

Question

data.table मैनुअल से:

वास्तव में हम चाहते यह इतना है कि data.table एक गिनती तरह आर के आंतरिक वैश्विक स्ट्रिंग कैश का उपयोग कर चरित्र वैक्टर के लिए एल्गोरिथ्म शामिल हैं। यह विशेष रूप से कैरेक्टर वैक्टरों के लिए तेज़ है जिसमें कई डुप्लिकेट हैं, जैसे कुंजी कॉलम में समूहित डेटा। इसका मतलब है कि चरित्र को अक्सर कारक के लिए प्राथमिकता दी जाती है। कारक अभी भी पूरी तरह से समर्थित हैं, विशेष रूप से आदेशित कारकों में (जहां स्तर वर्णमाला क्रम में नहीं हैं)।

factor सिर्फ पूर्णांक जो character से counting sort करना आसान होना चाहिए नहीं है?

Answer 1

कारक की तुलना में गिनती करने के लिए कारक केवल पूर्णांक नहीं होना चाहिए?

हां, अगर आपको पहले से ही एक कारक दिया गया है। लेकिन उस कारक को बनाने का समय महत्वपूर्ण हो सकता है और यह setkey (और विज्ञापन by) का लक्ष्य है। यादृच्छिक रूप से आदेशित चरित्र वेक्टर पर factor() का समय आज़माएं, 1e4 स्तरों के साथ 1e6 लंबा कहें। फिर मूल यादृच्छिक रूप से आदेशित वर्ण वेक्टर पर setkey या विज्ञापन by पर तुलना करें।

agstudy की टिप्पणी भी सही है; यानी, चरित्र वैक्टर (आर कैश स्ट्रिंग्स के पॉइंटर्स होने के नाते) वैसे भी कारकों के समान हैं। 32 बिट सिस्टम पर चरित्र वैक्टर कारक के पूर्णांक वेक्टर के समान आकार होते हैं लेकिन कारक में स्टोर करने के लिए स्तर विशेषता होती है (और कभी-कभी प्रतिलिपि भी होती है)। 64 बिट सिस्टम पर पॉइंटर्स दो गुना बड़ा होते हैं। लेकिन दूसरी ओर आर के स्ट्रिंग कैश को सीधे चरित्र वेक्टर पॉइंटर्स से देखा जा सकता है, जबकि कारक के स्तर के माध्यम से अतिरिक्त हॉप है। (स्तर विशेषता आर स्ट्रिंग कैश पॉइंटर्स का एक चरित्र वेक्टर भी है।)