Pandas: कुल प्रतिलिपि, प्रस्तावित समाधान के बिना मिश्रित dtype DataFrame बनाने का कोई तरीका नहीं है

आप बस एक इंडेक्स और कॉलम के साथ एक खाली फ्रेम बना सकते हैं
फिर ndarrays असाइन करें - ये आप की प्रतिलिपि नहीं करेंगे, एक ही समय में एक विशेष प्रकार के सभी असाइन करें

आप चाहें तो इन्हें np.empty से बना सकते हैं

df = pd.DataFrame(index=range(2), columns=["dude", "wheres"])

df
Out[12]:
  dude wheres
0  NaN    NaN
1  NaN    NaN

x = np.empty(2, np.int32)

x
Out[14]: array([6, 0], dtype=int32)

df.dude = x

df
Out[16]:
   dude wheres
0     6    NaN
1     0    NaN

x[0] = 0

x
Out[18]: array([0, 0], dtype=int32)

df
Out[19]:
   dude wheres
0     6    NaN
1     0    NaN

ऐसा लगता है कि यह मेरी नकल कर रहा है। जब तक मैंने जो कोड लिखा है वह वह नहीं है जो आपका मतलब है, या जो प्रतिलिपि हुई है वह वह प्रतिलिपि नहीं है जिसे आपने सोचा था कि मैं दूर करने की कोशिश कर रहा था।

आपने dtype बदल दिया है
इसलिए यह एक फ्लोट के साथ कोशिश की नकल की

y = np.empty(2, np.float64)

df
Out[21]:
   dude wheres
0     6    NaN
1     0    NaN

df.wheres = y

y
Out[23]: array([  2.96439388e-323,   2.96439388e-323])

y[0] = 0

df
Out[25]:
   dude         wheres
0     6  2.964394e-323
1     0  2.964394e-323

df = pd.DataFrame(index=range(2), columns=["dude", "wheres"])

df.dtypes
Out[27]:
dude      object
wheres    object
dtype: object

dtype ऑब्जेक्ट है, इसलिए इसका कोई फर्क नहीं पड़ता कि मैं फ्लोट या इंट का उपयोग करता हूं या नहीं।

In [25]: arr = np.ones((2,3))

In [26]: df = DataFrame(arr,columns=['a','b','c'])

In [27]: arr[0,1] = 5

In [28]: df
Out[28]: 
   a  b  c
0  1  5  1
1  1  1  1

मिश्रित प्रकार पर w/oa प्रतिलिपि का निर्माण किया जा सकता है लेकिन यह काफी मुश्किल है। समस्या यह है कि कुछ प्रकार की प्रतिलिपि की आवश्यकता होती है (उदाहरण के लिए स्मृति विवाद मुद्दों से बचने के लिए ऑब्जेक्ट)। और आंतरिक संरचना विभिन्न प्रकारों को समेकित करती है, इसलिए एक नया प्रकार जोड़ने के लिए एक प्रति की आवश्यकता होगी। ज्यादातर मामलों में कॉपी से बचना काफी मुश्किल होता है।

आपको केवल वही बनाना चाहिए जो आपको चाहिए, डेटा पर पॉइंटर्स प्राप्त करें और फिर इसे ओवरराइट करें। वह एक समस्या क्यों है?

समस्या यह है कि मुझे जो चाहिए उसे बनाने के लिए, मुझे सही प्रकार की सामग्री में प्रतिलिपि बनाना होगा, जिसके डेटा का उपयोग करने का मेरा कोई इरादा नहीं है। यहां तक ​​​​कि यह मानते हुए कि खाली डेटाफ़्रेम बनाने का आपका सुझाव कोई महत्वपूर्ण रैम का उपयोग नहीं करता है, यह कॉपी करने की लागत को कम नहीं करता है। अगर मैं 1 गीगाबाइट डेटाफ़्रेम बनाना चाहता हूं और इसे कहीं और पॉप्युलेट करना चाहता हूं, तो मुझे मेमोरी में चारों ओर एक गीगाबाइट कचरे की प्रतिलिपि बनाने की लागत का भुगतान करना होगा, जो पूरी तरह से अनावश्यक है। क्या आप इसे समस्या के रूप में नहीं देखते हैं?

हां, मैं समझता हूं कि आंतरिक संरचना विभिन्न प्रकारों को समेकित करती है। मुझे यकीन नहीं है कि स्मृति विवाद के मुद्दों से आपका क्या मतलब है, लेकिन किसी भी मामले में वस्तुएं वास्तव में यहां रुचि नहीं रखती हैं।

वास्तव में, जबकि सामान्य रूप से प्रतियों से बचना एक कठिन समस्या है, मेरे द्वारा सुझाए गए तरीके से उनसे बचना काफी आसान है क्योंकि मैं शुरुआत से ही सभी आवश्यक जानकारी प्रदान कर रहा हूँ। यह डेटा से निर्माण के समान है, सिवाय इसके कि डेटा से dtypes और # पंक्तियों का अनुमान लगाने और डेटा की प्रतिलिपि बनाने के बजाय, आप dtypes और # पंक्तियों को सीधे निर्दिष्ट करते हैं, और बाकी सब ठीक उसी तरह करते हैं जैसे आपने कॉपी को घटाकर किया होगा।

आपको प्रत्येक समर्थित कॉलम प्रकार के लिए "खाली" कन्स्ट्रक्टर की आवश्यकता है। संख्यात्मक संख्यात्मक प्रकारों के लिए यह स्पष्ट है, इसे श्रेणीबद्ध के लिए गैर-शून्य कार्य की आवश्यकता है, डेटाटाइम इंडेक्स के बारे में अनिश्चित।

कंस्ट्रक्टर को एक निर्देश पास करना और कॉपी करना = गलत काम करना चाहिए

तो यह काम करेगा। लेकिन आपको यह सुनिश्चित करना होगा कि आप जिन सरणियों से गुजर रहे हैं वे अलग-अलग प्रकार के हैं। और एक बार जब आप इसमें कुछ भी करते हैं तो यह अंतर्निहित डेटा की प्रतिलिपि बना सकता है। तो वाईएमएमवी। आप निश्चित रूप से उस शून्य/शून्य के बजाय np.empty में पास कर सकते हैं जो मैं हूं।

In [75]: arr = np.ones((2,3))

In [76]: arr2 = np.zeros((2,2),dtype='int32')

In [77]: df = DataFrame(arr,columns=list('abc'))

In [78]: df2 = DataFrame(arr2,columns=list('de'))

In [79]: result = pd.concat([df,df2],axis=1,copy=False)

In [80]: arr2[0,1] = 20

In [81]: arr[0,1] = 10

In [82]: result
Out[82]: 
   a   b  c  d   e
0  1  10  1  0  20
1  1   1  1  0   0

In [83]: result._data
Out[83]: 
BlockManager
Items: Index([u'a', u'b', u'c', u'd', u'e'], dtype='object')
Axis 1: Int64Index([0, 1], dtype='int64')
FloatBlock: slice(0, 3, 1), 3 x 2, dtype: float64
IntBlock: slice(3, 5, 1), 2 x 2, dtype: int32

In [84]: result._data.blocks[0].values.base
Out[84]: 
array([[  1.,  10.,   1.],
       [  1.,   1.,   1.]])

In [85]: result._data.blocks[1].values.base
Out[85]: 
array([[ 0, 20],
       [ 0,  0]], dtype=int32)

_प्रारंभिक प्रयास को हटा दिया गया क्योंकि reindex फोर्स कास्टिंग के बाद से काम नहीं करता है, जो एक अजीब "फीचर" है।

'विधि' का उपयोग करना होगा, जो इस प्रयास को थोड़ा कम संतोषजनक बनाती है:

arr = np.empty(1, dtype=[('x', np.float), ('y', np.int)])
df = pd.DataFrame.from_records(arr).reindex(np.arange(100))

यदि आप वास्तव में प्रदर्शन के बारे में चिंतित हैं, तो मुझे यकीन नहीं है कि कोई जितना संभव हो सके numpy का उपयोग क्यों नहीं करेगा क्योंकि यह अवधारणात्मक रूप से बहुत आसान है।

जेरेबैक, आपके समाधान के लिए धन्यवाद। यह काम करने लगता है, यहां तक ​​​​कि श्रेणीबद्धों के लिए भी (जिसने मुझे चौंका दिया)। अगर मुझे समस्याएं आती हैं तो मैं आपको बता दूंगा। मुझे यकीन नहीं है कि आपका क्या मतलब है: यदि आप इसके लिए कुछ भी करते हैं, तो यह प्रतिलिपि बना सकता है। किसी भी चीज़ से आपका क्या मतलब है? जब तक गाय शब्दार्थ नहीं हैं, मुझे लगता है कि आप जो देखते हैं वह वही है जो आपको निर्माण के समय गहरी बनाम उथली प्रतियों के संबंध में मिलता है।

मुझे अभी भी लगता है कि एक from_empty कंस्ट्रक्टर को लागू किया जाना चाहिए, और मुझे नहीं लगता कि यह इतना मुश्किल होगा, जबकि यह तकनीक काम करती है, इसमें बहुत सारे कोड ओवरहेड शामिल होते हैं। सिद्धांत रूप में यह एक एकल समग्र प्रकार और कई पंक्तियों को निर्दिष्ट करके किया जा सकता है।

बैशटेज, ये समाधान अभी भी संपूर्ण डेटाफ़्रेम में लिखते हैं। चूंकि लेखन आमतौर पर पढ़ने की तुलना में धीमा होता है, इसका मतलब है कि यह प्रश्न में आधे से भी कम ओवरहेड बचाता है।

जाहिर है अगर मैं नहीं गया और numpy का उपयोग नहीं किया है, इसका कारण यह है कि पांडा में कई अद्भुत विशेषताएं और क्षमताएं हैं जो मुझे पसंद हैं, और मैं उन्हें छोड़ना नहीं चाहता हूं। क्या आप वास्तव में पूछ रहे थे, या सिर्फ यह कह रहे थे कि अगर मैं इस प्रदर्शन को हिट नहीं करना चाहता तो मुझे numpy का उपयोग करना चाहिए?

इसे स्क्रैच करें, कृपया, उपयोगकर्ता त्रुटि, और मेरी क्षमायाचना। प्रतिलिपि के साथ reindex_axis = गलत पूरी तरह से काम किया।

बैशटेज, ये समाधान अभी भी संपूर्ण डेटाफ़्रेम में लिखते हैं। चूंकि लेखन आमतौर पर पढ़ने की तुलना में धीमा होता है, इसका मतलब है कि यह प्रश्न में आधे से भी कम ओवरहेड बचाता है।

यह सच है, लेकिन सभी यह है कि आप की जरूरत है एक नया method के लिए reindex कि कुछ भी से भरना नहीं होगा और फिर आप / लेखन के बिना मनमाने ढंग से कॉलम प्रकार के साथ एक टाइप सरणी आवंटित कर सकते हैं को कॉपी।

जाहिर है अगर मैं नहीं गया और numpy का उपयोग नहीं किया है, इसका कारण यह है कि पांडा में कई अद्भुत विशेषताएं और क्षमताएं हैं जो मुझे पसंद हैं, और मैं उन्हें छोड़ना नहीं चाहता हूं। क्या आप वास्तव में पूछ रहे थे, या सिर्फ यह कह रहे थे कि अगर मैं इस प्रदर्शन को हिट नहीं करना चाहता तो मुझे numpy का उपयोग करना चाहिए?

यह थोड़ा अलंकारिक था - हालांकि प्रदर्शन के दृष्टिकोण से एक गंभीर सुझाव भी है क्योंकि numpy डेटा-ए-ए-ब्लॉब-ऑफ-मेमोरी एक्सेस के करीब पहुंचना बहुत आसान बनाता है जो महत्वपूर्ण है यदि आप बहुत लिखने की कोशिश कर रहे हैं उच्च प्रदर्शन कोड। जब कोड सादगी प्रदर्शन से अधिक महत्वपूर्ण होती है, तो आप हमेशा सुन्न से पांडा में बदल सकते हैं।

जो आप कह रहे हैं, वो मुझे समझ आ रहा है। मुझे अभी भी लगता है कि इसे वर्कअराउंड के बजाय इंटरफ़ेस का अधिक स्पष्ट रूप से हिस्सा होना चाहिए, लेकिन जैसे-जैसे वर्कअराउंड चलते हैं यह एक अच्छा और लागू करने में आसान है।

पंडों ने अभी भी प्रदर्शन पर जोर दिया है यदि इसका मुख्य उद्देश्य है। जाहिर है इसमें numpy की तुलना में उच्च स्तर की विशेषताएं हैं, और इनके लिए भुगतान करना होगा। हम जिस बारे में बात कर रहे हैं उसका उन उच्च स्तरीय सुविधाओं से कोई लेना-देना नहीं है, और ऐसा कोई कारण नहीं है कि किसी को उन जगहों पर भारी प्रतियों के लिए भुगतान करना चाहिए जहां आपको उनकी आवश्यकता नहीं है। आपका सुझाव उचित होगा यदि कोई कॉलम, इंडेक्स आदि को स्थापित करने की लागत के बारे में बदबू कर रहा था, जो इस चर्चा से बिल्कुल अलग है।

मुझे लगता है कि आप पाइथन में स्मृति आवंटित करने के कोड बनाम लेखन की लागत को अधिक महत्व दे रहे हैं - महंगा हिस्सा स्मृति आवंटन है। वस्तु निर्माण भी महंगा है।

दोनों 1GB मेमोरी आवंटित करते हैं, एक खाली और एक शून्य।

%timeit np.empty(1, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 2.44 µs per loop

%timeit np.zeros(1, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 2.47 µs per loop

%timeit np.zeros(50000000, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 11.7 µs per loop

%timeit np.empty(50000000, dtype=[('x', float), ('y', int), ('z', float)])
100000 loops, best of 3: 11.4 µs per loop

150,000,000 मानों को शून्य करने के लिए 3µs।

अब इनकी तुलना एक तुच्छ DataFrame के लिए करें।

%timeit pd.DataFrame([[0]])
1000 loops, best of 3: 426 µs per loop

तुच्छ के लिए लगभग 200 गुना धीमा। लेकिन यह बड़े सरणियों के लिए कहीं अधिक खराब है।

%timeit pd.DataFrame(np.empty((50000000, 3)),copy=False)
1 loops, best of 3: 275 ms per loop

अब इसमें 275 m s लगते हैं -- ध्यान दें कि यह कुछ भी कॉपी नहीं कर रहा है। लागत सूचकांक आदि को स्थापित करने में है, जो स्पष्ट रूप से बहुत धीमी है जब सरणी गैर-तुच्छ रूप से बड़ी होती है।

यह मेरे लिए एक समयपूर्व अनुकूलन की तरह लगता है क्योंकि पांडा में अन्य ओवरहेड इतने बड़े हैं कि मॉलोक + फिलिंग घटक 0 लागत के करीब है।

ऐसा लगता है कि यदि आप एक तंग लूप में कुछ भी आवंटित करना चाहते हैं जो प्रदर्शन कारणों से एक numpy array होना चाहिए।

ठीक है, मुझे लगता है कि हमें क्या करना चाहिए, @quicknir अगर आप कुछ सुधार करना चाहते हैं। 2 मुद्दे।

• #4464 - यह अनिवार्य रूप से DataFrame कंस्ट्रक्टर में एक कंपाउंड dtype की अनुमति दे रहा है और फिर चारों ओर मुड़कर from_records() कॉल कर रहा है, जिसे पास किया गया सरणी एक rec/संरचित सरणी होने पर भी कहा जा सकता है - यह मूल रूप से from_records rec/संरचित सरणी प्रसंस्करण पथ बना देगा
• copy= कीवर्ड से from_records
• from_records फिर concat soln का उपयोग कर सकते हैं जो मैं ऊपर दिखाता हूं, रिक-सरणी को विभाजित करने के बजाय, उन्हें (श्रृंखला के रूप में) स्वच्छ करना और फिर उन्हें वापस एक साथ रखना (dtype ब्लॉक में; यह हिस्सा आंतरिक रूप से किया जाता है)।

यह थोड़ा गैर-तुच्छ है लेकिन फिर किसी को पहले से बनाए गए ndarray (खाली हो सकता है) में मिश्रित प्रकारों के साथ आसानी से पारित करने की अनुमति मिलती है। ध्यान दें कि यह संभवतः (पहले पास कार्यान्वयन में) केवल (int/float/string) को संभालेगा। चूंकि डेटाटाइम/टाइमडेल्टा को विशेष स्वच्छता की आवश्यकता होती है और यह थोड़ा और जटिल बना देगा।

इसलिए @bashtage एक पूर्ण दृष्टिकोण से सही है। फ्रेम का निर्माण करने के लिए यह बहुत समझ में आता है जैसा कि आप चाहते हैं, फिर ndarrays को संशोधित करें (लेकिन आपको ब्लॉक को पकड़कर ऐसा करना होगा, अन्यथा आपको प्रतियां मिल जाएंगी)।

ऊपर जो मेरा मतलब था वह यह है। पांडा किसी भी तरह के प्रकार (जैसे int64, int32 अलग हैं) को 'ब्लॉक' (फ्रेम में 2-डी) में समूहित करता है। ये एक सन्निहित मेमोरी ndarray हैं (जो कि नव आवंटित है, जब तक कि इसे केवल पास नहीं किया जाता है जिसमें केवल वर्तमान में एक ही dtype के लिए काम करता है)। यदि आप एक सेटिटम करते हैं, उदाहरण के लिए df['new_columns'] = 5 और आपके पास पहले से ही एक int64 ब्लॉक है, तो यह नया कॉलम अंततः इसके साथ जुड़ जाएगा (जिसके परिणामस्वरूप उस dtype के लिए एक नया मेमोरी आवंटन होगा)। यदि आप इस पर एक संदर्भ के रूप में एक संदर्भ का उपयोग कर रहे थे तो यह अब मान्य नहीं होगा। इसलिए यह ऐसी रणनीति नहीं है जिसे आप डेटाफ़्रेम इंटर्नल पर w/o पीयरिंग नियोजित कर सकते हैं।

@bashtage ये बड़ी लागत सूचकांक है जैसा आपने नोट किया है। एक RangeIndex (#939 देखें) इस समस्या को पूरी तरह से हल कर देगा। (यह वास्तव में लगभग एक साइड ब्रांच में किया जाता है, बस कुछ डस्टिंग की जरूरत होती है)।

यहां तक ​​​​कि एक अनुकूलित RangeIndex भी यह एक NumPy सरणी के निर्माण की तुलना में धीमी परिमाण के 2 ऑर्डर होंगे, जो कि बहुत अधिक वजन प्रकृति और DataFrame अतिरिक्त क्षमताओं को देखते हुए काफी उचित है।

मुझे लगता है कि इसे केवल एक सुविधा फ़ंक्शन माना जा सकता है, न कि एक प्रदर्शन समस्या। यह मिश्रित प्रकार DataFrame या Panel जैसे को प्रारंभ करने के लिए उपयोगी हो सकता है।

dtype=np.dtype([('GDP', np.float64), ('Population', np.int64)])
pd.Panel(items=['AU','AT'],
         major_axis=['1972','1973'],
         minor_axis=['GDP','Population'], 
         dtype=[np.float, np.int64])

यह केवल एक एपीआई / सुविधा मुद्दा है

सहमत हैं कि पूर्ण वास्तव में एक आकस्मिक मुद्दा है (और चालक नहीं)

@bashtage

%timeit pd.DataFrame(np.empty((100, 1000000)))
100 लूप, सर्वश्रेष्ठ 3:15.6 ms प्रति लूप

%timeit pd.DataFrame(np.empty((100, 1000000)), कॉपी=सच)
1 लूप, सर्वोत्तम 3:302 ms प्रति लूप

इसलिए डेटाफ़्रेम में कॉपी करने में डेटाफ़्रेम बनाने में शामिल अन्य सभी कार्यों की तुलना में 20 गुना अधिक समय लगता है, अर्थात प्रतिलिपि (और अतिरिक्त आवंटन) 95% समय है। आपने जिन बेंचमार्क को सही चीज़ के लिए बेंचमार्क नहीं किया है। चाहे प्रतिलिपि स्वयं हो या आवंटन में समय लग रहा हो, वास्तव में कोई फर्क नहीं पड़ता, मुद्दा यह है कि यदि मैं एक से अधिक प्रकार के डेटाफ़्रेम के लिए प्रतियों से बच सकता हूँ जिस तरह से मैं एक एकल dtype डेटाफ़्रेम के लिए कर सकता हूँ तो मैं बहुत अधिक समय बचा सकता हूँ।

परिमाण तर्क के आपके दो क्रम भी धोखा दे रहे हैं। यह एकमात्र ऑपरेशन नहीं है जो किया जा रहा है, ऐसे अन्य ऑपरेशन भी किए जा रहे हैं जिनमें समय लगता है, जैसे डिस्क पढ़ता है। अभी, डेटाफ़्रेम बनाने के लिए मुझे जो अतिरिक्त प्रतिलिपि करने की ज़रूरत है, वह मेरे साधारण प्रोग्राम में लगभग आधा समय ले रहा है जो डिस्क से डेटा को डेटाफ़्रेम में पढ़ता है। यदि इसमें 1/20 वां अधिक समय लगता है, तो डिस्क रीड प्रमुख होगा (जैसा होना चाहिए) और आगे के सुधारों का लगभग कोई प्रभाव नहीं होगा।

इसलिए मैं आप दोनों पर फिर से जोर देना चाहता हूं: यह एक वास्तविक प्रदर्शन मुद्दा है।

jreback, यह देखते हुए कि संघटन रणनीति श्रेणीबद्धों के लिए काम नहीं करती है, यह मत सोचिए कि आपके द्वारा ऊपर सुझाए गए सुधार काम करेंगे। मुझे लगता है कि एक बेहतर प्रारंभिक बिंदु रीइंडेक्स होगा। अभी मुद्दा यह है कि रीइंडेक्स बहुत सारी अतिरिक्त चीजें करता है। लेकिन सिद्धांत रूप में, शून्य पंक्तियों वाले डेटाफ़्रेम में कोई अनावश्यक कार्य किए बिना, पंक्तियों की सही संख्या के साथ डेटाफ़्रेम के निर्माण की अनुमति देने के लिए आवश्यक सभी जानकारी होती है। बीटीडब्ल्यू, यह मुझे वास्तव में ऐसा महसूस कराता है जैसे पांडा को स्कीमा ऑब्जेक्ट की आवश्यकता होती है, लेकिन यह एक और दिन के लिए एक चर्चा है।

मुझे लगता है कि हमें असहमत होने के लिए सहमत होना होगा। IMO डेटाफ़्रेम संख्यात्मक पारिस्थितिकी तंत्र में चरम प्रदर्शन ऑब्जेक्ट नहीं हैं, जैसा कि एक बुनियादी सुपीरियर सरणी और डेटाफ़्रेम निर्माण के बीच परिमाण अंतर के क्रम से दिखाया गया है।

%timeit np.empty((1000000, 100))
1000 loops, best of 3: 1.61 ms per loop

%timeit pd.DataFrame(np.empty((1000000,100)))
100 loops, best of 3: 15.3 ms per loop

अभी, डेटाफ़्रेम बनाने के लिए मुझे जो अतिरिक्त प्रतिलिपि करने की ज़रूरत है, वह मेरे साधारण प्रोग्राम में लगभग आधा समय ले रहा है जो डिस्क से डेटा को डेटाफ़्रेम में पढ़ता है। यदि इसमें 1/20 वां अधिक समय लगता है, तो डिस्क रीड प्रमुख होगा (जैसा होना चाहिए) और आगे के सुधारों का लगभग कोई प्रभाव नहीं होगा।

मुझे लगता है कि डेटाफ़्रेम के प्रदर्शन की परवाह करने का यह और भी कम कारण है - भले ही आप इसे 100% मुफ़्त बना सकते हैं, कुल कार्यक्रम का समय केवल 50% कम हो जाता है।

मैं सहमत हूं कि इस मुद्दे को हल करने के लिए आपके लिए यहां पीआर करने की गुंजाइश है, चाहे आप इसे एक प्रदर्शन मुद्दे के रूप में या एक सुविधा के मुद्दे के रूप में सोचना चाहते हैं। मेरे पीओवी से, मैं इसे बाद वाले के रूप में देखता हूं क्योंकि जब मैं प्रदर्शन करता हूं तो मैं हमेशा एक numpy सरणी का उपयोग करूंगा। Numpy अन्य चीजें करता है जैसे ब्लॉक मैनेजर का उपयोग नहीं करना जो कुछ चीजों के लिए अपेक्षाकृत कुशल है (जैसे कॉलम जोड़कर सरणी बढ़ाना)। लेकिन अन्य दृष्टिकोण से बुरा।

दो विकल्प हो सकते हैं। पहला, एक खाली कंस्ट्रक्टर जैसा कि मैंने ऊपर दिए उदाहरण में दिया है। यह कुछ भी कॉपी नहीं करेगा, लेकिन पंडों में अन्य चीजों के अनुरूप होने के लिए शायद नल-फिल होगा। नल भरना बहुत सस्ता है और आईएमओ की समस्या की जड़ में नहीं है।

दूसरा तरीका DataFrame.from_blocks होगा जो पहले से तैयार किए गए ब्लॉक को सीधे ब्लॉक मैनेजर के पास ले जाएगा। कुछ इस तरह

DataFrame.from_blocks([np.empty((100,2)), 
                       np.empty((100,3), dtype=np.float32), 
                       np.empty((100,1), dtype=np.int8)],
                     columns=['f8_0','f8_1','f4_0','f4_1','f4_2','i1_0'],
                     index=np.arange(100))

इस प्रकार की एक विधि लागू करेगी कि ब्लॉकों में संगत आकार है, सभी ब्लॉकों में अद्वितीय प्रकार हैं, साथ ही साथ सूचकांक और स्तंभों के आकार के लिए सामान्य जांच भी है। इस प्रकार की विधि डेटा के लिए कुछ नहीं करेगी और इसे BlockManger में उपयोग करेगी।

@quicknir आप बहुत जटिल चीजों को गठबंधन करने की कोशिश कर रहे हैं। श्रेणीबद्ध numpy में मौजूद नहीं है, बल्कि वे एक मिश्रित प्रकार हैं जैसे कि एक पांडा निर्माण है। आपको अलग से निर्माण और असाइन करना होगा (जो वास्तव में काफी सस्ता है - ये अन्य एकवचन प्रकार की तरह ब्लॉक में संयुक्त नहीं हैं)।

@bashtage soln उचित लगता है। यह कुछ सरल जांच प्रदान कर सकता है और केवल डेटा के माध्यम से पास हो सकता है (और अन्य आंतरिक दिनचर्या द्वारा बुलाया जा सकता है)। आम तौर पर उपयोगकर्ता को आंतरिक प्रतिनिधि के साथ खुद को चिंतित करने की आवश्यकता नहीं होती है। चूंकि आप वास्तव में चाहते हैं, तो आपको इसके बारे में पता होना चाहिए।

उस सब ने कहा, मुझे अभी भी यकीन नहीं है कि आप ठीक उसी तरह एक फ्रेम क्यों नहीं बनाते जैसा आप चाहते हैं। फिर ब्लॉक पॉइंटर्स को पकड़ें और मान बदलें। इसकी एक ही मेमोरी खर्च होती है, और जैसा कि @bashtage बताता है कि यह अनिवार्य रूप से एक शून्य फ्रेम बनाने के लिए बहुत सस्ता है (जिसमें सभी प्रकार के टाइप, इंडेक्स, कॉलम हैं) पहले से ही सेट हैं।

सुनिश्चित नहीं है कि खाली कंस्ट्रक्टर से आपका क्या मतलब है, लेकिन यदि आपका मतलब बिना पंक्तियों और वांछित स्कीमा और कॉलिंग रीइंडेक्स के साथ डेटाफ़्रेम का निर्माण करना है, तो यह कॉपी = ट्रू के साथ बनाने में उतना ही समय है।

आपका दूसरा प्रस्ताव उचित है, लेकिन केवल तभी जब आप यह समझ सकें कि श्रेणीबद्ध कैसे करें। उस विषय पर, मैं कोड पढ़ रहा था और मैंने महसूस किया कि श्रेणीबद्ध गैर-समेकन योग्य हैं। तो एक झुकाव पर, मैंने एक पूर्णांक सरणी और दो श्रेणीबद्ध श्रृंखला बनाई, फिर मैंने तीन डेटाफ्रेम बनाए, और तीनों को संयोजित किया। निश्चित रूप से, यह एक प्रतिलिपि नहीं करता था, भले ही दो डेटाफ्रेम में एक ही प्रकार का प्रकार था। मैं यह देखने की कोशिश करूंगा कि इसे डेटाटाइम इंडेक्स के लिए कैसे काम करना है।

@jreback मैं अभी भी उस फ्रेम का पालन नहीं करता जो आप चाहते हैं जैसा फ्रेम बनाना चाहते हैं।

@quicknir आप वास्तव में जो करने की कोशिश कर रहे हैं उसका कोड/छद्म कोड नमूना क्यों नहीं दिखाते हैं।

def read_dataframe(filename, ....):
   f = my_library.open(filename)
   schema = f.schema()
   row_count = f.row_count()
   df = pd.DataFrame.from_empty(schema, row_count)
   dict_of_np_arrays = get_np_arrays_from_DataFrame(df)
   f.read(dict_of_np_arrays)
   return df

पिछला कोड पहले numpy arrays का एक डिक्शनरी बना रहा था, और उसके बाद डेटाफ्रेम का निर्माण कर रहा था क्योंकि यह सब कुछ कॉपी कर रहा था। लगभग आधा समय उसी पर खर्च हो रहा था। इसलिए मैं इसे इस योजना में बदलने की कोशिश कर रहा हूं। बात यह है कि जब आप सामग्री की परवाह नहीं करते हैं तब भी उपरोक्त के रूप में डीएफ बनाना बेहद महंगा है।

एनपी सरणियों के @quicknir तानाशाही के लिए बहुत सारी नकल की आवश्यकता होती है।

आपको बस यह करना चाहिए:

# construct your biggest block type (e.g. say you have mostly floats)
df = DataFrame(np.empty((....)),index=....,columns=....)

# then add in other things you need (say strings)
df['foo'] = np.empty(.....)

# say ints
df['foo2'] = np.empty(...)

यदि आप इसे dtype द्वारा करते हैं तो यह सस्ता होगा

फिर।

for dtype, block in df.as_blocks():
    # fill the values
    block.values[0,0] = 1

चूंकि ये ब्लॉक मान numpy arrays में विचार हैं

प्रकारों की संरचना सामान्य रूप से पहले से ज्ञात नहीं है, और सबसे आम उपयोग के मामले में फ्लोट्स और इनट्स का एक स्वस्थ मिश्रण होता है। मुझे लगता है कि मैं इसका पालन नहीं करता कि यह कैसे सस्ता होगा, अगर मेरे पास 30 फ्लोट कॉलम और 10 इंट कॉलम हैं, तो हां, फ्लोट बहुत सस्ते होंगे। लेकिन जब आप इनट्स करते हैं, जब तक कि उन सभी को एक बार में करने का कोई तरीका नहीं है, तो हर बार जब आप इनट्स का एक और कॉलम जोड़ते हैं तो यह पूरे int ब्लॉक को फिर से आवंटित करने का कारण बनता है।

जो समाधान आपने मुझे पहले दिया था वह काम करने के करीब है, मैं इसे डेटाटाइम इंडेक्स के लिए काम नहीं कर सकता।

सुनिश्चित नहीं है कि खाली कंस्ट्रक्टर से आपका क्या मतलब है, लेकिन यदि आपका मतलब बिना पंक्तियों और वांछित स्कीमा और कॉलिंग रीइंडेक्स के साथ डेटाफ़्रेम का निर्माण करना है, तो यह कॉपी = ट्रू के साथ बनाने में उतना ही समय है।

एक खाली कंस्ट्रक्टर ऐसा दिखेगा

dtype=np.dtype([('a', np.float64), ('b', np.int64), ('c', np.float32)])
df = pd.DataFrame(columns='abc',index=np.arange(100),dtype=dtype)

यह उसी आउटपुट का उत्पादन करेगा जैसे

dtype=np.dtype([('a', np.float64), ('b', np.int64), ('c', np.float32)])
arr = np.empty(100, dtype=dtype)
df = pd.DataFrame.from_records(arr, index=np.arange(100))

केवल यह डेटा कॉपी नहीं करेगा।

मूल रूप से कंस्ट्रक्टर निम्नलिखित कॉल के लिए मिश्रित प्रकार की अनुमति देगा जो काम करता है लेकिन केवल एक ही मूल प्रकार है।

df = pd.DataFrame(columns=['a','b','c'],index=np.arange(100), dtype=np.float32)

केवल अन्य _feature_ इसे अशक्त-भरने वाले इंट सरणियों से रोकने के लिए होगा, जिसका साइड इफेक्ट उन्हें ऑब्जेक्ट dtype में बदलने का है क्योंकि इनट्स के लिए कोई लापता मूल्य नहीं है।

आपका दूसरा प्रस्ताव उचित है, लेकिन केवल तभी जब आप यह समझ सकें कि श्रेणीबद्ध कैसे करें। उस विषय पर, मैं कोड पढ़ रहा था और मैंने महसूस किया कि श्रेणीबद्ध गैर-समेकन योग्य हैं। तो एक झुकाव पर, मैंने एक पूर्णांक सरणी और दो श्रेणीबद्ध श्रृंखला बनाई, फिर मैंने तीन डेटाफ्रेम बनाए, और तीनों को संयोजित किया। निश्चित रूप से, यह एक प्रतिलिपि नहीं करता था, भले ही दो डेटाफ्रेम में एक ही प्रकार का प्रकार था। मैं यह देखने की कोशिश करूंगा कि इसे डेटाटाइम इंडेक्स के लिए कैसे काम करना है।

from_block विधि को समेकन के नियमों को जानना होगा, ताकि यह कई श्रेणीबद्धों को अनुमति दे, लेकिन अन्य मूल प्रकारों में से केवल एक ही।

हाँ...यह करना इतना कठिन नहीं है...किसी ऐसे व्यक्ति की तलाश में है जो आंतरिक लोगों से एक सौम्य परिचय चाहता है... संकेत.संकेत.संकेत.... :)

हाहा, मैं कुछ कार्यान्वयन कार्य करने को तैयार हूं, मुझे गलत मत समझो। मैं इस सप्ताह के अंत में इंटर्नल को देखने की कोशिश करूंगा और यह समझूंगा कि किस कंस्ट्रक्टर को लागू करना आसान है। सबसे पहले हालांकि मुझे कुछ डेटाटाइम इंडेक्स मुद्दों से निपटने की ज़रूरत है जो मेरे पास एक अलग धागे में हैं।

@quicknir क्या आपको

मैं साइथन लाइब्रेरी से कॉलम की कॉपी-कम भरने की अनुमति देने के लिए मिश्रित-डीटाइप डेटाफ्रेम को सस्ते में आवंटित (लेकिन भरना नहीं) करने का एक तरीका ढूंढ रहा हूं।

यह बहुत अच्छा होगा यदि आप शुरू करने में मेरी सहायता के लिए आपके पास कोई भी कोड (यहां तक ​​​​कि अर्ध-कार्यरत) साझा करने के इच्छुक थे।

क्या निम्नलिखित एक समझदार दृष्टिकोण होगा? मैंने प्रोटोटाइप डेटाफ्रेम से काम करके अवरुद्ध तर्क को फिर से बनाया है।

श्रेणीबद्धों के अलावा किन प्रकारों को विशेष उपचार की आवश्यकता होती है?

बेशक, बनाए गए डेटाफ़्रेम का उपयोग तब तक सुरक्षित नहीं है जब तक कि इसे भर नहीं दिया जाता है ...

import numpy as np
from pandas.core.index import _ensure_index
from pandas.core.internals import BlockManager
from pandas.core.generic import NDFrame
from pandas.core.frame import DataFrame
from pandas.core.common import CategoricalDtype
from pandas.core.categorical import Categorical
from pandas.core.index import Index

def allocate_like(df, size, keep_categories=False):
    # define axes (waiting for #939 (RangeIndex))
    axes = [df.columns.values.tolist(), Index(np.arange(size))]

    # allocate and create blocks
    blocks = []
    for block in df._data.blocks:
        # special treatment for non-ordinary block types
        if isinstance(block.dtype, CategoricalDtype):
            if keep_categories:
                categories = block.values.categories
            else:
                categories = Index([])
            values = Categorical(values=np.empty(shape=block.values.shape,
                                                 dtype=block.values.codes.dtype),
                                 categories=categories,
                                 fastpath=True)
        # ordinary block types
        else:
            new_shape = (block.values.shape[0], size)
            values = np.empty(shape=new_shape, dtype=block.dtype)

        new_block = block.make_block_same_class(values=values,
                                                placement=block.mgr_locs.as_array)
        blocks.append(new_block)

    # create block manager
    mgr = BlockManager(blocks, axes)

    # create dataframe
    return DataFrame(mgr)


# create a prototype dataframe
import pandas as pd
a = np.empty(0, dtype=('i4,i4,f4,f4,f4,a10'))
df = pd.DataFrame(a)
df['cat_col'] = pd.Series(list('abcabcdeff'), dtype="category")

# allocate an alike dataframe
df1 = allocate_like(df, size=10)

@ ARF1 वास्तव में निश्चित नहीं है कि अंतिम लक्ष्य क्या है
क्या आप एक साधारण उदाहरण प्रदान कर सकते हैं?

कॉपी के साथ आगे समवर्ती = झूठा आम तौर पर यह कदम उठाएगा

@jreback मैं एक संपीड़ित डेटा स्टोर से बड़ी मात्रा में डेटा कॉलम-बाय-कॉलम पढ़ने के लिए एक साइथन लाइब्रेरी का उपयोग करना चाहता हूं जिसे मैं प्रदर्शन कारणों से मध्यस्थ प्रतिलिपि के बिना सीधे डेटाफ्रेम में असम्पीडित करना चाहता हूं।

ऐसे मामलों में सामान्य numpy समाधान से उधार लेना, मैं डेटाफ्रेम के लिए स्मृति को पूर्व-आवंटित करना चाहता हूं ताकि मैं इन आवंटित स्मृति क्षेत्रों में पॉइंटर्स को मेरी साइथन लाइब्रेरी में पास कर सकूं जो सामान्य सी-पॉइंटर्स/सी-एरे का उपयोग कर सकता है उन स्मृति क्षेत्रों को मध्यस्थ प्रतिलिपि चरणों (या मध्यस्थ पायथन वस्तुओं की पीढ़ी) के बिना सीधे डेटाफ्रेम भरने के लिए। जारी गिल के साथ समानांतर में कई साइथन थ्रेड्स के साथ डेटाफ्रेम भरने का विकल्प एक फ्रिंज लाभ होगा।

(सरलीकृत) छद्म कोड में मुहावरा कुछ ऐसा होगा:

df = fn_to_allocate_memory()
colums = df.columns.values
column_indexes = []
for i in xrange(len(df._data.blocks)):
    column_indexes.extend(df._data.blocks[i].mgr_locs.as_array)
block_arrays = [df._data.blocks[i].values for i in len(df._data.blocks)]

some_cython_library.fill_dataframe_with_content(columns, column_indexes, block_arrays)

क्या आपको यह बात ठीक लगती है?

जैसा कि मैं समझता हूं कि concat साथ copy=False समान dtypes वाले कॉलम को ब्लॉक में नहीं जोड़ेंगे, लेकिन लाइन के नीचे के संचालन इसे ट्रिगर करेंगे - जिसके परिणामस्वरूप मैं बचने की कोशिश कर रहा हूं। या क्या मैंने पांडा के आंतरिक संचालन को गलत समझा?

जबकि मैंने बड़े (गैर-भरे हुए) डेटाफ्रेम (कारक ~ 6.7) की तात्कालिकता के साथ कुछ प्रगति की है, मैं अभी भी सुन्न गति से दूर हूं। ~ 90 का केवल एक और कारक जाने के लिए...

In [157]: a = np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4,a10'))

In [158]: df = pd.DataFrame(a)

In [162]: %timeit np.empty(int(1e6), dtype=('i8,i4,i4,f4,f4,f4,a10'))
1000 loops, best of 3: 247 µs per loop

In [163]: %timeit allocate_like(df, size=int(1e6))
10 loops, best of 3: 22.4 ms per loop

In [164]: %timeit pd.DataFrame(np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4,a10')))

10 loops, best of 3: 150 ms per loop

एक और उम्मीद यह थी कि यह दृष्टिकोण समान आकार के डेटाफ़्रेम के त्वरित दोहराव को त्वरित रूप से दोहराए जाने की अनुमति दे सकता है जब छोटे-मात्रा वाले डेटा को बार-बार पढ़ा जाता है। यह अब तक का मुख्य उद्देश्य नहीं रहा है, लेकिन अनजाने में मैंने इसके साथ बेहतर प्रगति की: केवल ~ 4.8 का एक कारक सुन्न गति पर जाने के लिए।

In [157]: a = np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4,a10'))

In [158]: df = pd.DataFrame(a)

In [159]: %timeit np.empty(0, dtype=('i8,i4,i4,f4,f4,f4,a10'))
10000 loops, best of 3: 79.9 µs per loop

In [160]: %timeit allocate_like(df, size=0)
1000 loops, best of 3: 379 µs per loop

In [161]: %timeit pd.DataFrame(np.empty(0, dtype=('i4,i4,f4,f4,f4,a10')))
1000 loops, best of 3: 983 µs per loop

संपादित करें

उपरोक्त समय बहुत निराशावादी चित्र चित्रित कर रहे हैं क्योंकि वे सेब की तुलना संतरे से करते हैं: जबकि सुन्न स्ट्रिंग कॉलम को देशी स्ट्रिंग्स की लंबाई के रूप में बनाया जाता है, पांडा में समकक्ष कॉलम को पायथन ऑब्जेक्ट सरणी के रूप में बनाया जाएगा। समान रूप से तुलना करने से डेटाफ़्रेम इंस्टेंटेशन को इंडेक्स जनरेशन के अपवाद के साथ सुन्न गति पर धकेल दिया जाता है जो इंस्टेंटेशन समय के लगभग 92% के लिए जिम्मेदार होता है।

@ ARF1 यदि आप तेज गति चाहते हैं, तो बस numpy का उपयोग करें। मुझे यकीन नहीं है कि आप वास्तव में क्या कर रहे हैं या आप साइथन में क्या कर रहे हैं। सामान्य सॉलन्स आपकी गणनाओं को तोड़ना, साइथन को एकल प्रकार पास करना या बस एक बड़ी मशीन प्राप्त करना है।

डेटाफ़्रेम डेटा का वर्णन और हेरफेर करने के तरीके के बारे में बहुत कुछ कर रहे हैं। यह वह नहीं है जो आप वास्तव में उनके साथ कर रहे हैं।

लगभग सभी पांडा ऑपरेशन कॉपी। (जैसा कि अधिकांश सुन्न संचालन करते हैं), इसलिए सुनिश्चित न करें कि आप क्या कर रहे हैं।

@jreback मैं वर्तमान में numpy का उपयोग कर रहा हूं लेकिन मेरे पास मिश्रित प्रकार हैं जो केवल (सुविधाजनक रूप से) संरचित सरणी के साथ संभाला जा सकता है। हालांकि संरचित सरणियाँ स्वाभाविक रूप से पंक्ति-प्रमुख आदेशित हैं जो मेरे विशिष्ट विश्लेषण आयाम के साथ खराब प्रदर्शन की ओर ले जाती हैं। पांडा अपने कॉलम-प्रमुख ऑर्डरिंग के कारण प्राकृतिक विकल्प की तरह दिखते हैं - अगर मैं डेटा को अच्छी गति से डेटाफ्रेम में प्राप्त कर सकता हूं।

बेशक विकल्प अलग-अलग टाइप किए गए numpy arrays के एक ताना का उपयोग करेगा, लेकिन इससे विश्लेषण दर्द होता है क्योंकि स्लाइसिंग आदि अब संभव नहीं है।

सामान्य सॉलन्स आपकी गणनाओं को खंडित करना है, साइथन को एकल प्रकार पास करना है।

मैं अपने उदाहरण में block_arrays चर के साथ यही कर रहा हूं।

या बस एक बड़ी मशीन प्राप्त करें।

100+ तेज का एक कारक मेरे लिए एक वित्तीय चुनौती है। ;-)

@ ARF1 आपके पास एक बहुत ही अजीब मॉडल है कि चीजें कैसे काम करती हैं। आमतौर पर आप कम संख्या में डेटा फ़्रेम बनाते हैं, फिर उन पर काम करते हैं। निर्माण की गति किसी भी वास्तविक गणना या हेरफेर का एक छोटा सा अंश है।

@jreback : यह एक अजीब मॉडल नहीं है। यदि आप चीजों को शुद्ध अजगर के नजरिए से देखते हैं तो शायद यह एक अजीब मॉडल है। यदि आप सी ++ कोड के साथ काम कर रहे हैं, तो पाइथन ऑब्जेक्ट्स में डेटा पढ़ने का सबसे आसान तरीका है कि इसे पॉइंटर्स को पहले से मौजूद पायथन ऑब्जेक्ट्स में पास करना है। यदि आप इसे प्रदर्शन संवेदनशील संदर्भ में कर रहे हैं, तो आप पाइथन ऑब्जेक्ट बनाने के लिए एक सस्ता और स्थिर (स्मृति स्थान के अर्थ में) तरीका चाहते हैं।

मुझे ईमानदारी से यकीन नहीं है कि पांडा बोर्डों पर यह रवैया आम क्यों है। मुझे लगता है कि यह दुर्भाग्यपूर्ण है, जहां तक ​​​​मैं समझता हूं कि पांडा सुन्न की तुलना में एक उच्च स्तर का निर्माण है, फिर भी लोगों के लिए पांडा के "शीर्ष पर" विकसित करना आसान हो सकता है। पांडा डेटाफ़्रेम अब तक काम करने के लिए सबसे वांछनीय प्रकार है यदि आपके पास सी कोड है जो सारणीबद्ध डेटा को अजगर में थूकना चाहता है, तो यह वास्तव में एक महत्वपूर्ण उपयोग के मामले की तरह लगता है।

कृपया वह न लें जो मैं नकारात्मक रूप से लिख रहा हूं, अगर मुझे नहीं लगता कि पांडा डेटाफ्रेम इतने भयानक थे, तो मैं सिर्फ सुन्न रिकॉर्ड या ऐसा कुछ उपयोग करूंगा और इसके साथ किया जाएगा।

@ ARF1 : आखिरकार, मुझे कारण याद नहीं हैं, लेकिन सबसे अच्छा मैं यह करने में सक्षम था कि कॉपी = गलत के साथ एक संख्यात्मक सरणी से प्रत्येक संख्यात्मक प्रकार के लिए डेटाफ्रेम बनाना, और फिर कॉपी = गलत के साथ pandas.concat का उपयोग करें। उन्हें जोड़ने के लिए। जब आप एक numpy array से एक ही प्रकार का DataFrame बनाते हैं, तो numpy array के ओरिएंटेशन के बारे में बहुत सावधान रहें। यदि ओरिएंटेशन गलत है, तो प्रत्येक कॉलम से संबंधित numpy arrays गैर-तुच्छ रूप से घुमावदार होंगे, और पांडा इसे पसंद नहीं करते हैं और पहले अवसर पर एक प्रतिलिपि बनायेंगे। आप अंत में श्रेणीबद्धों से निपट सकते हैं, क्योंकि वे समेकित नहीं होते हैं और शेष फ्रेम की किसी भी प्रतियों को ट्रिगर नहीं करना चाहिए।

मैं कुछ यूनिट परीक्षण लिखने की अनुशंसा करता हूं जो इस ऑपरेशन को चरण दर चरण निष्पादित करते हैं और लगातार पॉइंटर्स को अंतर्निहित डेटा (अंतर्निहित numpy सरणी के array_interface के माध्यम से) पर पकड़ते हैं और सत्यापित करते हैं कि वे यह सुनिश्चित करने के लिए समान हैं कि प्रतिलिपि वास्तव में समाप्त हो रही है। पंडों द्वारा यह एक बहुत ही दुर्भाग्यपूर्ण निर्णय है कि कॉपी/इनप्लेस पैरामीटर्स को सम्मानित करने की आवश्यकता नहीं है। यही है, भले ही आप डेटाफ़्रेम कंस्ट्रक्टर के लिए कॉपी = गलत सेट करते हैं, फिर भी पांडा एक कॉपी का प्रदर्शन करेंगे यदि यह तय करता है कि डेटाफ़्रेम के निर्माण के लिए इसकी आवश्यकता है। तथ्य यह है कि जब तर्कों को सम्मानित नहीं किया जा सकता है तो पांडा इसे फेंकने के बजाय ऐसा करता है जो विश्वसनीय रूप से कोड लिखता है जो प्रतियों को बहुत थकाऊ बनाता है, और बेहद व्यवस्थित होने की आवश्यकता होती है। यदि आप सत्यापित करने के लिए इकाई परीक्षण नहीं लिखते हैं, तो आप गलती से बाद में कुछ ऐसा कर सकते हैं जिसके कारण प्रतिलिपि बनाई जा सकती है, और यह चुपचाप होगा और आपके प्रदर्शन को बर्बाद कर देगा।

@quicknir अगर आप ऐसा कहते हैं। मुझे लगता है कि चीजों को अनुकूलित करने का प्रयास करने से पहले आपको बस प्रोफाइल करना चाहिए। जैसा कि मैंने पहले कहा, और फिर से जांच होगी। निर्माण का समय किसी भी चीज पर हावी नहीं होना चाहिए। यदि ऐसा होता है, तो आप चीजों को रखने के लिए केवल डेटाफ्रेम का उपयोग कर रहे हैं, तो इसे पहले स्थान पर उपयोग करने का क्या मतलब है? अगर यह हावी नहीं है, तो समस्या क्या है?

@jreback आप यह मानते हुए लिखते हैं कि मैंने पहले ही प्रोफाइल नहीं किया है। वास्तव में, मेरे पास है। हमारे पास सी ++ और पायथन कोड है जो दोनों एक ही डेटा प्रारूप से सारणीबद्ध डेटा को डी-सीरियलाइज करते हैं। जबकि मुझे उम्मीद थी कि पायथन कोड में थोड़ा सा ओवरहेड होगा, मुझे लगा कि अंतर छोटा होना चाहिए, क्योंकि डिस्क पढ़ने का समय हावी होना चाहिए। यह मामला नहीं था, इससे पहले कि मैं गया और बहुत सावधानी से कॉपियों को कम करने के लिए चीजों को फिर से काम किया, अजगर संस्करण सी ++ कोड की तुलना में दो बार लंबा या बदतर ले रहा था, और लगभग सभी ओवरहेड सिर्फ डेटाफ्रेम बनाने में था। दूसरे शब्दों में, एक निश्चित बहुत बड़े आकार का डेटाफ़्रेम बनाने में लगभग उतना ही समय लगा, जिसकी सामग्री की मुझे बिल्कुल भी परवाह नहीं थी, जैसे कि उस डेटाफ़्रेम में मेरे द्वारा देखे गए डेटा को पढ़ना, डीकंप्रेस करना और लिखना। यह बेहद खराब प्रदर्शन है।

यदि मैं विशिष्ट संचालन को ध्यान में रखते हुए इस कोड का अंतिम उपयोगकर्ता था, तो हो सकता है कि आप निर्माण के बारे में जो कह रहे हैं वह हावी नहीं होगा। वास्तव में, मैं एक डेवलपर हूं, और इस कोड के अंतिम उपयोगकर्ता अन्य लोग हैं। मुझे नहीं पता कि वे डेटाफ़्रेम के साथ क्या कर रहे होंगे, डेटाफ़्रेम डिस्क पर डेटा की स्मृति प्रतिनिधित्व प्राप्त करने का एक तरीका है। यदि वे डिस्क पर डेटा के साथ कुछ बहुत ही सरल करना चाहते हैं, तो उन्हें अभी भी डेटाफ़्रेम प्रारूप से गुजरना होगा।

जाहिर है, मैं डेटा प्राप्त करने के और तरीकों का समर्थन कर सकता हूं (उदाहरण के लिए numpy निर्माण), लेकिन यह कोड में ब्रांचिंग में काफी वृद्धि करेगा, और डेवलपर के रूप में मेरे लिए चीजों को और अधिक कठिन बना देगा। यदि कोई मूलभूत कारण था कि डेटाफ़्रेम को इतना धीमा होने की आवश्यकता क्यों है, तो मैं समझूंगा, और तय करूँगा कि डेटाफ़्रेम, सुन्न, या दोनों का समर्थन करना है या नहीं। लेकिन कोई वास्तविक कारण नहीं है कि इसे इतना धीमा होने की आवश्यकता क्यों है। कोई एक DataFrame.empty विधि लिख सकता है जो टुपल्स की एक सरणी लेता है जहां प्रत्येक टपल में कॉलम का नाम और प्रकार, और पंक्तियों की संख्या होती है।

मेरे द्वारा समर्थित उपयोक्ताओं और पुस्तकालय लेखकों के बीच यही अंतर है। लाइब्रेरी लिखने की तुलना में अपना कोड लिखना ज्यादा आसान है। और यह आसान है कि आपकी लाइब्रेरी अन्य लाइब्रेरी लेखकों के बजाय केवल उपयोगकर्ताओं का समर्थन करे। मुझे लगता है कि इस मामले में, डेटाफ़्रेम का खाली आवंटन पांडा में कम लटका हुआ फल होगा जो मेरे और @ ARF1 जैसे लोगों के जीवन को आसान बना देगा।

ठीक है अगर आप एक उचित परीक्षण किए गए दस्तावेज सॉल, सभी कानों को प्राप्त करना चाहते हैं। पांडा के पास कुछ उपयोगकर्ता/डेवलपर्स हैं। यही कारण है कि डेटाफ़्रेम इतना बहुमुखी है और यही कारण है कि इसे बहुत सारी त्रुटि जाँच और अनुमान की आवश्यकता है। ऊपर बताए अनुसार आप क्या कर सकते हैं, यह देखने के लिए आपका स्वागत है।

मैं इसे लागू करने में कुछ समय लगाने को तैयार हूं, लेकिन केवल तभी जब कुछ पांडा डेवलपर्स से डिजाइन पर कुछ उचित सहमति हो। अगर मैं एक पुल अनुरोध सबमिट करता हूं और कुछ चीजें हैं जिन्हें लोग बदलना चाहते हैं, तो यह अच्छा है। या अगर मैं इसमें दस घंटे लगाने के बाद महसूस करता हूं कि सफाई से कुछ करने का कोई तरीका नहीं है, और इसे करने का एकमात्र तरीका कुछ ऐसा शामिल हो सकता है जिसे लोग आपत्तिजनक मानते हैं, यह भी अच्छा है। लेकिन मैं एक्स घंटे खर्च करने के साथ वास्तव में अच्छा नहीं हूं और कहा जा रहा है कि यह उपयोगी नहीं है, कार्यान्वयन गड़बड़ है, हमें नहीं लगता कि इसे वास्तव में साफ किया जा सकता है, कोडबेस को जटिल करता है, आदि। मुझे नहीं पता कि क्या मैं इस भावना से दूर हूं, मैंने पहले किसी ओएसएस परियोजना में बड़ा योगदान नहीं दिया है इसलिए मुझे नहीं पता कि यह कैसे काम करता है। यह सिर्फ इतना है कि अपनी प्रारंभिक पोस्ट में मैंने इसी चीज़ का प्रस्ताव देना शुरू कर दिया था, और फिर स्पष्ट रूप से मुझे आपसे यह आभास हुआ कि यह पंडों के लिए "दायरे से बाहर" था।

यदि आप चाहें तो मैं एक नया मुद्दा खोल सकता हूं, जितना हो सके उतना विशिष्ट डिजाइन प्रस्ताव तैयार कर सकता हूं, और एक बार फीडबैक/अस्थायी अनुमोदन होने पर मैं सक्षम होने पर उस पर काम करूंगा।

@quicknir मुख्य बात यह है कि इसे पूरे टेस्ट सूट को पास करना होगा, जो कि काफी व्यापक है।

यह पांडा के दायरे से बाहर नहीं है, लेकिन एपीआई कुछ हद तक उपयोगकर्ता के अनुकूल होना चाहिए।

मुझे यकीन नहीं है कि आपको क्यों पसंद नहीं आया

concat(list_of_arrays,axis=1,copy=False) मेरा मानना ​​है कि यह वही करता है जो आप चाहते हैं (और यदि नहीं, तो स्पष्ट न करें कि आप वास्तव में क्या चाहते हैं)।

मैं एक समान तकनीक का उपयोग कर समाप्त हुआ, लेकिन डेटाफ्रेम की एक सूची के साथ जो एक ही numpy सरणी से बनाए गए थे, प्रत्येक अलग-अलग प्रकार के।

सबसे पहले, मुझे लगता है कि जब मैंने यह तकनीक की थी तब भी मैं कुछ प्रतियों में भाग गया था। जैसा कि मैंने कहा, पांडा हमेशा कॉपी = गलत का सम्मान नहीं करते हैं, इसलिए यह देखना बहुत थकाऊ है कि आपका कोड वास्तव में कॉपी कर रहा है या नहीं। मैं वास्तव में चाहता हूं कि पांडा 17 के लिए, देव कॉपी = ट्रू डिफॉल्ट बनाने पर विचार करेंगे, और फिर कॉपी = गलत फेंकता है जब एक कॉपी को मिटाया नहीं जा सकता है। लेकिन वैसे भी।

दूसरा, एक और मुद्दा बाद में कॉलम को फिर से व्यवस्थित करना था। यह आश्चर्यजनक रूप से अजीब था, एक प्रतिलिपि के बिना ऐसा करने का एकमात्र तरीका मूल रूप से कॉलम नाम पूर्णांक बनाना था जिसे वांछित अंतिम क्रम में आदेश दिया गया था। मैंने तब एक इंडेक्स सॉर्ट किया था। मैंने फिर कॉलम नाम बदल दिए।

तीसरा, मैंने पाया कि टाइमस्टैम्प प्रकारों (numpy datetime64) के लिए प्रतियां अपरिहार्य थीं।

मैंने यह कोड कुछ समय पहले लिखा था इसलिए यह मेरे दिमाग में ताज़ा नहीं है। यह संभव है कि मैंने गलतियाँ की हों, लेकिन मैंने इसे बहुत सावधानी से देखा और वे परिणाम थे जो मैं उस समय लेकर आया था।

आपके द्वारा ऊपर दिया गया कोड numpy arrays के लिए भी काम नहीं करता है। इसके साथ विफल रहता है: TypeError: एक गैर-NDFrame ऑब्जेक्ट को संयोजित नहीं कर सकता। आपको पहले उन्हें डेटाफ़्रेम बनाना होगा।

ऐसा नहीं है कि आपने यहां या ऊपर जो समाधान दिया है, वह मुझे पसंद नहीं है। मुझे अभी तक एक साधारण काम करना बाकी है।

@quicknir अच्छी तरह से ऊपर मेरा उदाहरण काम करता है। कृपया वही प्रदान करें जो आप कर रहे हैं और मैं आपकी मदद करने की कोशिश कर सकता हूं।

pd.concat([np.zeros((2,2))], अक्ष = 1, कॉपी = गलत)

मैं पांडा 0.15.2 पर हूं, तो शायद इसने 0.16 में काम करना शुरू कर दिया?

कृपया pd.concat की दस्तावेज़-स्ट्रिंग पढ़ें। आपको एक DataFrame

बीटीडब्ल्यू copy=True डिफ़ॉल्ट है

ठीक यही मैंने लिखा है। आपके द्वारा ऊपर लिखे गए कोड स्निपेट में list_of_arrays था, न कि list_of_dataframes। वैसे भी, मुझे लगता है कि हम एक दूसरे को समझते हैं। मैंने pd.concat विधि का उपयोग करके समाप्त किया, लेकिन यह बहुत गैर-तुच्छ है, लोगों की यात्रा करने के लिए गोचा का एक पूरा समूह है:

1) आपको DataFrames की एक सूची बनानी होगी। प्रत्येक डेटाफ़्रेम में बिल्कुल एक विशिष्ट प्रकार का होना चाहिए। तो आपको शुरू करने से पहले सभी अलग-अलग dtypes को इकट्ठा करना होगा।

2) प्रत्येक डेटाफ़्रेम को वांछित dtype, समान पंक्तियों की संख्या, स्तंभों की वांछित संख्या, और क्रम = 'F' ध्वज के एकल numpy सरणी से बनाया जाना चाहिए; अगर आदेश = 'सी' (डिफ़ॉल्ट) तो पांडा अक्सर प्रतियां बनाते हैं जब यह अन्यथा नहीं होता।

3) अवहेलना 1) श्रेणीबद्धों के लिए, उन्हें एक ब्लॉक में समामेलित नहीं किया जाता है ताकि आप बाद में उनसे निपट सकें।

4) जब आप सभी अलग-अलग डेटाफ़्रेम बनाते हैं, तो कॉलम को पूर्णांकों का उपयोग करके नामित किया जाना चाहिए जो उस क्रम का प्रतिनिधित्व करते हैं जिसमें आप उन्हें चाहते हैं। अन्यथा प्रतियों को ट्रिगर किए बिना कॉलम क्रम को बदलने का कोई तरीका नहीं हो सकता है।

5) डेटाफ़्रेम की अपनी सूची बनाने के बाद, कॉन्सैट का उपयोग करें। आपको श्रमसाध्य रूप से सत्यापित करना होगा कि आपने कुछ भी गड़बड़ नहीं किया है, क्योंकि कॉपी = गलत नहीं फेंकेगा अगर एक कॉपी को हटा नहीं दिया जा सकता है, बल्कि चुपचाप कॉपी करें।

6) अपने इच्छित क्रम को प्राप्त करने के लिए कॉलम इंडेक्स को सॉर्ट करें, फिर कॉलम का नाम बदलें।

मैंने इस प्रक्रिया को सख्ती से लागू किया। यह एक लाइनर नहीं है, गलतियाँ करने के लिए बहुत सारे स्थान हैं, मुझे पूरा यकीन है कि यह अभी भी टाइमस्टैम्प के लिए काम नहीं करता है, और बहुत सारे अनावश्यक ओवरहेड हैं जिन्हें केवल इंटरफ़ेस का उपयोग न करके समाप्त किया जा सकता है। यदि आप चाहें, तो मैं केवल सार्वजनिक एपीआई का उपयोग करके यह फ़ंक्शन कैसा दिखता है, इसका एक मसौदा लिख ​​सकता हूं, यह देखने के लिए कि क्या यह वास्तव में प्रतियां हैं, और जिसके लिए dtypes.

साथ ही, कॉपी = गलत डिफ़ॉल्ट है, उदाहरण के लिए डेटाफ्रेम कंस्ट्रक्टर। मेरा मुख्य बिंदु यह है कि एक फ़ंक्शन जो अपने तर्कों का सम्मान नहीं कर सकता है उसे "कुछ उचित करें" के बजाय फेंक देना चाहिए। यही है, अगर कॉपी = गलत को सम्मानित नहीं किया जा सकता है, तो एक अपवाद को फेंक दिया जाना चाहिए ताकि उपयोगकर्ता को पता चले कि उन्हें या तो अन्य इनपुट बदलना होगा ताकि कॉपी एलिजन हो सके, या उन्हें कॉपी को ट्रू में बदलना होगा। कॉपी = गलत होने पर एक कॉपी कभी भी चुपचाप नहीं होनी चाहिए, यह प्रदर्शन के प्रति जागरूक उपयोगकर्ता के लिए बग खोजने के लिए अधिक आश्चर्यजनक और कम अनुकूल है।

आपके यहाँ बहुत सारे चरण हैं जो आवश्यक नहीं हैं
कृपया एक वास्तविक उदाहरण दिखाएं जैसा मैंने ऊपर किया था

आप समझते हैं कि एक नुकीला दृश्य बहुत ही सरल रीशेपिंग ऑपरेशंस (कभी-कभी) द्वारा एक प्रतिलिपि वापस कर सकता है और अन्य नहीं

प्रतिलिपि पर केवल एक सॉफ्ट गारंटी होने जा रही है क्योंकि यह गारंटी देने के लिए बहुत अधिक आत्मनिरीक्षण के बिना आमतौर पर संभव नहीं है जो परिभाषा के अनुसार सरल शक्तिशाली प्रदर्शन कोड के उद्देश्य को हरा देता है

DataFrame निर्माण में copy=False का व्यवहार numpy के np.array फ़ंक्शन के अनुरूप है (उदाहरण के लिए, यदि आप सरणियों की सूची प्रदान करते हैं, तो अंतिम डेटा हमेशा एक प्रतिलिपि बनाएगा)।

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

हमें एक वैकल्पिक डेटाफ़्रेम कार्यान्वयन की आवश्यकता है जो विशेष रूप से सुव्यवस्थित डेटा के साथ काम करने के लिए डिज़ाइन किया गया है जो प्रत्येक कॉलम को स्वतंत्र रूप से 1D numpy arrays के रूप में संग्रहीत करता है। यह वास्तव में कुछ हद तक xray में डेटा मॉडल के समान है, सिवाय इसके कि हम कॉलम को एन-आयामी सरणी होने की अनुमति देते हैं।

मेरा मानना ​​​​है कि एक सामान्य उच्च-प्रदर्शन पांडा डेटाफ़्रेम कंस्ट्रक्टर जो केवल स्थान आवंटित करता है, वह गैर-तुच्छ है जिसे विभिन्न कॉलम प्रकारों की विस्तृत श्रृंखला का समर्थन करने की आवश्यकता होगी।

ऐसा कहा जा रहा है, यह पुस्तकालय लेखकों के लिए काफी सीधे आगे लगता है जो पांडा डेटाफ्रेम को उच्च-प्रदर्शन डेटा कंटेनर के रूप में उपयोग करना चाहते हैं ताकि आवंटन-केवल डेटाफ्रेम कन्स्ट्रक्टर को कॉलम प्रकारों तक सीमित किया जा सके।

निम्नलिखित कोड खंड प्रेरणा के रूप में काम कर सकता है। यह आवंटन-केवल, गैर-भरे हुए डेटाफ़्रेम को खस्ता गति के करीब त्वरित करने की अनुमति देता है। ध्यान दें कि कोड को पीआर # 9977 की आवश्यकता है:

import numpy as np
from pandas.core.index import _ensure_index
from pandas.core.internals import BlockManager
from pandas.core.generic import NDFrame
from pandas.core.frame import DataFrame
from pandas.core.common import CategoricalDtype
from pandas.core.categorical import Categorical
from pandas.core.index import RangeIndex

def allocate_like(df, size, keep_categories=False):
    # define axes (uses PR #9977)
    axes = [df.columns.values.tolist(), RangeIndex(size)]

    # allocate and create blocks
    blocks = []
    for block in df._data.blocks:
        # special treatment for non-ordinary block types
        if isinstance(block.dtype, CategoricalDtype):
            if keep_categories:
                categories = block.values.categories
            else:
                categories = Index([])
            values = Categorical(values=np.empty(shape=block.values.shape,
                                                 dtype=block.values.codes.dtype),
                                 categories=categories,
                                 fastpath=True)
        # ordinary block types
        else:
            new_shape = (block.values.shape[0], size)
            values = np.empty(shape=new_shape, dtype=block.dtype)

        new_block = block.make_block_same_class(values=values,
                                                placement=block.mgr_locs.as_array)
        blocks.append(new_block)

    # create block manager
    mgr = BlockManager(blocks, axes)

    # create dataframe
    return DataFrame(mgr)

उदाहरण कंस्ट्रक्टर के साथ allocate_like() प्रदर्शन दंड cf numpy बड़े सरणियों के लिए केवल x2.3 (सामान्य रूप से x333) और शून्य-आकार के सरणियों के लिए x3.3 (सामान्य रूप से x8.9) है:

In [2]: import numpy as np

In [3]: import pandas as pd

In [4]: a = np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4'))

# create template-dataframe
In [5]: df = pd.DataFrame(a)

# large dataframe timings
In [6]: %timeit np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4'))
1000 loops, best of 3: 212 µs per loop

In [7]: %timeit allocate_like(df, size=int(1e6))
1000 loops, best of 3: 496 µs per loop

In [8]: %timeit pd.DataFrame(np.empty(int(1e6), dtype=('i4,i4,f4,f4,f4')))
10 loops, best of 3: 70.6 ms per loop

# zero-size dataframe timing
In [9]: %timeit np.empty(0, dtype=('i4,i4,f4,f4,f4'))
10000 loops, best of 3: 108 µs per loop

In [10]: %timeit allocate_like(df, size=0)
1000 loops, best of 3: 360 µs per loop

In [11]: %timeit pd.DataFrame(np.empty(0, dtype=('i4,i4,f4,f4,f4')))
1000 loops, best of 3: 959 µs per loop

क्षमा करें, मैंने कुछ समय के लिए इसका ट्रैक खो दिया। @ एआरएफ 1 , उपरोक्त कोड नमूने के लिए बहुत बहुत धन्यवाद। प्रदर्शन मेट्रिक्स के साथ-साथ बहुत अच्छा।

मैं वास्तव में महसूस करता हूं कि बिना किसी डेटा के डेटाफ्रेम के लेआउट से मेल खाने वाली कक्षा बनाना, कोड को और अधिक प्राकृतिक, और शायद अधिक प्रदर्शन करने वाला कोड बना देगा। पंक्तियों का पुन: अनुक्रमण करते समय इस वर्ग का पुन: उपयोग भी किया जा सकता है।

जो मैं मूल रूप से प्रस्तावित करता हूं वह कुछ ऐसा है: DataFrameLayout नामक एक वर्ग, जो dtypes, कॉलम नाम और कॉलम ऑर्डरिंग को लपेटता है। उदाहरण के लिए, यह dtype से कॉलम नंबर (ऑर्डर करने के लिए) और सभी नामों के साथ एक अलग ऐरे को स्टोर कर सकता है। इस लेआउट से, आप देख सकते हैं कि तानाशाही पर एक सरल, सुरुचिपूर्ण पुनरावृत्ति ब्लॉक प्रबंधकों को जल्दी से बनाने की अनुमति देगा। इस वर्ग का उपयोग खाली कंस्ट्रक्टर जैसी जगहों पर या रीइंडेक्सिंग ऑपरेशंस में किया जा सकता है।

मुझे लगता है कि अधिक जटिल डेटा के लिए ऐसे सार तत्व आवश्यक हैं। कुछ अर्थों में, DataFrame एक समग्र डेटा प्रकार है, और DataFrameLayout संरचना की सटीक प्रकृति को निर्दिष्ट करेगा।

वैसे, मुझे लगता है कि कुछ ऐसा ही Categoricals के लिए आवश्यक है; यह है कि एक श्रेणीबद्ध प्रकार का अमूर्त होना आवश्यक है जो श्रेणियों को संग्रहीत करता है, चाहे उन्हें आदेश दिया गया हो या नहीं, बैकिंग सरणी प्रकार, आदि। यानी, वास्तविक डेटा के अलावा सब कुछ। वास्तव में, जब आप डेटाफ़्रेमलेआउट के बारे में सोचते हैं, तो आप महसूस करते हैं कि सभी स्तंभों में पूरी तरह से निर्दिष्ट प्रकार होने चाहिए, और यह वर्तमान में श्रेणीबद्धों के लिए समस्याग्रस्त है।

लोग इन दो वर्गों के बारे में क्या सोचते हैं?

@quicknir हमारे पास पहले से ही CategoricalDtype वर्ग है -- मैं सहमत हूं कि इसे आपके द्वारा वर्णित पूर्ण CategoricalType तक बढ़ाया जा सकता है।

मैं DataFrameLayout वर्ग के बारे में पूरी तरह से निश्चित नहीं हूं। मूल रूप से, मुझे लगता है कि हम डेटा फ्रेम के लिए एक वैकल्पिक, सरल डेटा मॉडल का उपयोग कर सकते हैं (अधिक समान रूप से वे आर या जूलिया में कैसे किए जाते हैं)। इस तरह की चीज़ों में कुछ दिलचस्पी है और मुझे संदेह है कि यह अंततः किसी न किसी रूप में होगा, लेकिन शायद जल्द ही कभी नहीं (और शायद पांडा परियोजना के हिस्से के रूप में कभी नहीं)।

@quicknir ये, DataFrameLayout यहां पहिया को फिर से शुरू कर रहा है। हमारे पास पहले से ही एक प्रकार की युक्ति है, उदाहरण के लिए

In [14]: tm.makeMixedDataFrame().to_records().dtype
Out[14]: dtype([('index', '<i8'), ('A', '<f8'), ('B', '<f8'), ('C', 'O'), ('D', '<M8[ns]')])

@jreback यह पहिया को फिर से शुरू नहीं कर रहा है, क्योंकि dtype spec में कई बड़ी समस्याएं हैं:

1) जहाँ तक मैं देख सकता हूँ, to_records () संपूर्ण डेटाफ़्रेम की एक गहरी प्रतिलिपि करेगा। डेटाफ़्रेम के लिए कल्पना प्राप्त करना (मैं अभी से इस शब्द का उपयोग करूँगा) सस्ता और आसान होना चाहिए।

2) to_records का आउटपुट एक सुन्न प्रकार है। इसका एक निहितार्थ यह है कि मैं यह नहीं देखता कि इसे कभी भी श्रेणीबद्धों का उचित समर्थन करने के लिए कैसे बढ़ाया जा सकता है।

3) युक्ति को आंतरिक रूप से संग्रहीत करने की यह विधि आसानी से संगत नहीं है कि डेटा को डेटाफ़्रेम के अंदर कैसे संग्रहीत किया जाता है (अर्थात जैसे dtype के ब्लॉक में)। इस तरह के एक स्पेक से ब्लॉक बनाने में बहुत से अतिरिक्त काम शामिल होते हैं जिन्हें मैंने सुझाव दिया था, जैसे कि डीटाइप से कॉलम नंबरों तक एक निर्देश के साथ कल्पना को संग्रहीत करके समाप्त किया जा सकता है। जब आपके पास 2000 कॉलम वाला डेटाफ़्रेम होगा, तो यह महंगा होगा।

संक्षेप में, रिकॉर्ड प्रतिनिधित्व का प्रकार एक उचित युक्ति की कमी के लिए एक वैकल्पिक हल है। इसमें कई प्रमुख विशेषताओं का अभाव है और यह प्रदर्शन के लिहाज से बहुत खराब है।

SO पर इस सुविधा के लिए पूछने वाले कई सूत्र हैं।

मुझे ऐसा लगता है कि ये सभी समस्याएं ब्लॉकमैनेजर से अलग-अलग कॉलम को एक मेमोरी खंड ('ब्लॉक') में समेकित करने से उत्पन्न होती हैं।
कॉपी = गलत निर्दिष्ट होने पर डेटा को ब्लॉक में समेकित नहीं करना सबसे आसान समाधान नहीं होगा।

मेरे पास एक गैर-समेकित बंदर-पैच ब्लॉकमैनेजर है:
https://stackoverflow.com/questions/45943160/can-memmap-pandas-series-what-about-a-dataframe
कि मैं इस समस्या के आसपास काम करता था।