ज़्यादातर प्रोग्रामिंग टास्क के लिए, पेज का साइज़ ज़रूरी नहीं होता. हालांकि, अगर आपको ज़्यादा मेमोरी की ज़रूरत है, आपने कॉम्पोनेंट को ऑप्टिमाइज़ किया है, कर्नेल के साथ सीधे इंटरफ़ेस किया है या फ़ाइल में ज़्यादा बदलाव किए हैं, तो Android के 16 केबी पेज साइज़ पर माइग्रेट करने से, परफ़ॉर्मेंस के विश्लेषण में कुछ बातों का ध्यान रखना पड़ सकता है. इस दस्तावेज़ में, पेज के साइज़ में बदलाव करने से, परफ़ॉर्मेंस की डाइनैमिक्स पर पड़ने वाले असर के बारे में बताया गया है.
मेमोरी से जुड़ी समस्याओं का पता लगाना
mmap की मदद से मेमोरी को ऐलोकेट करते समय, पक्का करें कि आपने हमेशा ऐसा आर्ग्युमेंट पास किया हो जो पेज के साइज़ का मल्टीपल हो. अगर 16 केबी पेज साइज़ वाले सिस्टम पर 4096 बाइट का अनुरोध किया जाता है, तो कर्नेल 16 KB ऐलोकेट करता है. इससे 12 KB जगह बर्बाद हो जाती है. इन समस्याओं का पता लगाने के लिए, /proc/maps, /proc/smaps देखा जा सकता है. इसके अलावा, Android के showmap टूल का इस्तेमाल किया जा सकता है. यह टूल, बर्बाद हुई जगह को साफ़ तौर पर दिखाता है. साथ ही, अपने प्रोसेस का strace भी देखा जा सकता है.
डिस्क की जगह से जुड़ी समस्याओं का पता लगाना
Android 15 और उसके बाद के वर्शन पर लॉन्च होने वाले डिवाइसों में, डिफ़ॉल्ट रूप से 16 केबी अलाइन किए गए ईएलएफ़ होते हैं. साथ ही, कई ऐप्लिकेशन भी 16 केबी अलाइन किए गए होते हैं. सिस्टम कोई भी हो, कई फ़ाइलों में पैडिंग बढ़ गई है. डिस्क पर फ़ाइल का असली साइज़ देखने के लिए, आप
du <my file> का इस्तेमाल कर सकते हैं. इससे यह पता चलता है कि कोई फ़ाइल कितने किलोबाइट की है. किसी फ़ाइल का
साइज़ देखने के लिए, du -b <my file> का इस्तेमाल किया जा सकता है. इससे फ़ाइल का साइज़
बाइट में दिखता है. जब फ़ाइल का साइज़, असली साइज़ से ज़्यादा होता है, तो इसका मतलब है कि फ़ाइल कंप्रेस की गई है या उसमें स्पार्स रीजन हैं. जब फ़ाइल का साइज़, असली साइज़ से कम होता है, तो इसका मतलब है कि फ़ाइल में अतिरिक्त मेटाडेटा है या उसे डिस्क पर अलग-अलग हिस्सों में बांटा गया है. इन जांचों का इस्तेमाल करके, डिस्क पर मौजूद फ़ाइलों के असली साइज़ का विश्लेषण किया जा सकता है.