Чиста Гарвардська архітектура, як правило, дозволяє комп'ютеру з заданим рівнем складності працювати швидше, ніж архітектура Фон-Неймана, за умови, що між кодом і пам’яттю даних не потрібно ділитися ресурсами. Якщо обмеження чіткості або інші фактори змушують використовувати одну шину для доступу до обох просторів пам'яті, такі переваги, можливо, значною мірою скасовуються.
"Чиста" Гарвардська архітектура буде обмежена запущеним кодом, який зберігається в пам'яті якимсь механізмом, відмінним від процесора, який запускатиме код. Це обмежує корисність подібних архітектур для пристроїв, призначення яких не встановлено заводом (або комусь із спеціалізованим програмним обладнанням). Для полегшення цього питання можуть бути використані два підходи:
Деякі системи мають окремі області коду та пам’яті, але надають спеціальне обладнання, яке може бути запропоновано коротко взяти шину коду, виконати деяку операцію та повернути контроль до центрального процесора після завершення такої операції. Деякі такі системи потребують досить складного протоколу для проведення таких операцій, деякі мають спеціальні вказівки для виконання такого завдання, а деякі навіть спостерігають за певними адресами "пам'яті даних" та запускають передачу / випуск при спробі доступу до них. . Ключовим аспектом таких систем є те, що є чітко визначені області пам’яті для «коду» та «даних»; навіть якщо ЦП може прочитати та записати простір "коду", він все одно визнається як семантично відмінний від простору даних. "
Альтернативний підхід, який використовується в деяких системах вищого класу, полягає в тому, щоб встановити контролер з двома шинами пам'яті, одна для коду і одна для даних, обидві з яких підключаються до арбітражного блоку пам'яті. Цей блок, в свою чергу, підключений до різних підсистем пам'яті, використовуючи окрему шину пам'яті для кожної. Доступ до коду до однієї підсистеми пам'яті може оброблятися одночасно з доступом до даних до іншої; лише якщо код і дані намагаються одночасно отримати доступ до тієї ж підсистеми, або доведеться чекати.
У системах, що використовують такий підхід, не критичні для продуктивності частини програми можуть просто ігнорувати межі між підсистемами пам'яті. Якщо код і дані знаходяться в одній підсистемі пам'яті, речі не будуть працювати так швидко, як якщо б вони були в окремих підсистемах, але для багатьох частин типової програми це не має значення. У типовій системі буде невелика частина коду, де продуктивність дійсно має значення, і вона працюватиме лише на невеликій частині даних, що зберігаються системою. Якщо у вас була система з 16К оперативної пам’яті, яка була розділена на два 8К розділи, можна було використовувати вказівки лінкера, щоб переконатися, що критично важливий для роботи код був розташований поблизу початку загального простору пам’яті, а критично важливі показники - поблизу кінець. Якщо загальний розмір коду зростає, наприклад, до 9 К, код в останній 1K буде працювати повільніше, ніж код, розміщений в іншому місці, але цей код не буде критичним для продуктивності. Так само, якби код був, наприклад, лише 6К, але дані зросли до 9К, доступ до найнижчих 1К даних був би повільним, але якби критично важливі дані знаходилися в іншому місці, це не створювало б проблем.
Зауважте, що хоча продуктивність була б оптимальною, якби код був нижче 8K, а дані - під 8K, вищезгадана конструкція системи пам'яті не накладала б жодного суворого розділу між кодом та простором даних. Якщо програмі потрібно лише 1К даних, код може вирости до 15К. Якщо йому потрібно лише 2K коду, дані можуть зрости до 14K. Набагато більш універсальний, ніж наявність 8K просто для коду та 8K області лише для даних.