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