एक शुद्ध हार्वर्ड आर्किटेक्चर आमतौर पर एक कंप्यूटर को जटिल स्तर के साथ एक वॉन न्यूमन आर्किटेक्चर की तुलना में अधिक तेज़ी से चलाने की अनुमति देगा, बशर्ते कि किसी भी संसाधन को कोड और डेटा यादों के बीच साझा करने की आवश्यकता न हो। यदि पिनआउट सीमाएं या अन्य कारक दोनों मेमोरी स्पेस तक पहुंचने के लिए एक बस का उपयोग करने के लिए मजबूर करते हैं, तो ऐसे फायदे काफी हद तक शून्य हो जाते हैं।
एक "शुद्ध" हार्वर्ड आर्किटेक्चर रनिंग कोड तक सीमित होगा जो कि प्रोसेसर के अलावा कुछ तंत्र द्वारा मेमोरी में डाला जाता है जो कोड चलाएगा। यह उपकरणों के लिए ऐसे आर्किटेक्चर की उपयोगिता को सीमित करता है जिसका उद्देश्य कारखाने (या किसी विशेष प्रोग्रामिंग उपकरण वाले व्यक्ति) द्वारा निर्धारित नहीं है। इस समस्या को कम करने के लिए दो तरीकों का इस्तेमाल किया जा सकता है:
कुछ प्रणालियों में अलग-अलग कोड और मेमोरी क्षेत्र होते हैं, लेकिन विशेष हार्डवेयर प्रदान करते हैं जिन्हें संक्षेप में कोड बस पर ले जाने के लिए कहा जा सकता है, कुछ ऑपरेशन कर सकते हैं, और सीपीयू पर नियंत्रण वापस कर सकते हैं जैसे कि ऐसा ऑपरेशन पूरा हो गया है। कुछ ऐसी प्रणालियों को इस तरह के संचालन को करने के लिए एक काफी विस्तृत प्रोटोकॉल की आवश्यकता होती है, कुछ के पास ऐसे कार्य करने के लिए विशेष निर्देश होते हैं, और कुछ निश्चित "डेटा मेमोरी" पते के लिए भी देखते हैं और जब उन्हें एक्सेस करने का प्रयास किया जाता है तो अधिग्रहण / रिलीज को ट्रिगर करते हैं। । ऐसी प्रणालियों का एक महत्वपूर्ण पहलू यह है कि "कोड" और "डेटा" के लिए स्मृति के स्पष्ट रूप से परिभाषित क्षेत्र हैं; भले ही CPU के लिए "कोड" स्पेस को पढ़ना और लिखना संभव हो, फिर भी इसे डेटा स्पेस से शब्दार्थ के रूप में पहचाना जाता है। '
एक वैकल्पिक दृष्टिकोण जो कुछ उच्च-अंत प्रणालियों में उपयोग किया जाता है, दो मेमोरी बसों के साथ एक नियंत्रक होता है, एक कोड के लिए और एक डेटा के लिए, दोनों एक मेमोरी मध्यस्थता इकाई से जुड़ते हैं। वह इकाई बदले में प्रत्येक के लिए एक अलग मेमोरी बस का उपयोग करके विभिन्न मेमोरी सबसिस्टम से जुड़ी होती है। एक मेमोरी सबसिस्टम के लिए एक कोड एक्सेस को एक डेटा एक्सेस के साथ दूसरे में संसाधित किया जा सकता है; केवल अगर कोड और डेटा एक ही सबसिस्टम को एक साथ एक्सेस करने की कोशिश करते हैं तो या तो इंतजार करना होगा।
सिस्टम पर जो इस दृष्टिकोण का उपयोग करते हैं, एक कार्यक्रम के गैर-प्रदर्शन-महत्वपूर्ण हिस्से स्मृति उप-प्रणालियों के बीच की सीमाओं को अनदेखा कर सकते हैं। यदि कोड और डेटा एक ही मेमोरी सबसिस्टम में रहते हैं, तो चीजें उतनी तेजी से नहीं चलेंगी जैसे कि वे अलग-अलग सबसिस्टम में थीं, लेकिन एक विशिष्ट प्रोग्राम के कई हिस्सों के लिए जो मायने नहीं रखेगा। एक विशिष्ट प्रणाली में, कोड का एक छोटा हिस्सा होगा जहां प्रदर्शन वास्तव में मायने रखता है, और यह केवल सिस्टम द्वारा रखे गए डेटा के एक छोटे हिस्से पर काम करेगा। यदि किसी के पास 16K RAM के साथ एक प्रणाली थी जिसे दो 8K विभाजनों में विभाजित किया गया था, तो कोई यह सुनिश्चित करने के लिए लिंकर निर्देशों का उपयोग कर सकता है कि प्रदर्शन-महत्वपूर्ण कोड समग्र मेमोरी स्पेस की शुरुआत के पास स्थित था, और प्रदर्शन-महत्वपूर्ण डेटा पास था समाप्त। यदि कुल कोड आकार बढ़ता है जैसे 9K, अंतिम 1K के भीतर कोड कहीं और रखे गए कोड की तुलना में धीमी गति से चलेगा, लेकिन यह कोड प्रदर्शन के लिए महत्वपूर्ण नहीं होगा। इसी तरह, यदि कोड केवल 6K थे, लेकिन डेटा 9K तक बढ़ गया, तो सबसे कम 1K डेटा तक पहुंच धीमी होगी, लेकिन यदि प्रदर्शन-महत्वपूर्ण डेटा कहीं और स्थित थे, तो यह समस्या पैदा नहीं करेगा।
ध्यान दें कि प्रदर्शन इष्टतम होगा यदि कोड 8K के तहत थे और डेटा 8K के तहत थे, तो उपरोक्त मेमोरी-सिस्टम डिज़ाइन कोड और डेटा स्थान के बीच कोई सख्त विभाजन नहीं लगाएगा। यदि किसी प्रोग्राम को केवल 1K डेटा की आवश्यकता है, तो कोड 15K तक बढ़ सकता है। यदि इसे केवल 2K कोड की आवश्यकता है, तो डेटा 14K तक बढ़ सकता है। केवल कोड के लिए 8K क्षेत्र और डेटा के लिए 8K क्षेत्र होने की तुलना में बहुत अधिक बहुमुखी।