Une architecture Harvard pure permettra généralement à un ordinateur avec un niveau de complexité donné de fonctionner plus rapidement qu'une architecture Von Neuman, à condition qu'aucune ressource ne soit partagée entre le code et les mémoires de données. Si des limitations de brochage ou d'autres facteurs obligent l'utilisation d'un bus pour accéder aux deux espaces mémoire, ces avantages sont susceptibles d'être largement annulés.
Une architecture Harvard "pure" sera limitée à l'exécution de code qui est mis en mémoire par un mécanisme autre que le processeur qui exécutera le code. Cela limite l'utilité de telles architectures pour les appareils dont le but n'est pas défini par l'usine (ou quelqu'un avec un équipement de programmation spécialisé). Deux approches peuvent être utilisées pour atténuer ce problème:
Certains systèmes ont des zones de code et de mémoire distinctes, mais fournissent un matériel spécial auquel il peut être demandé de reprendre brièvement le bus de code, d'effectuer une opération et de retourner le contrôle à la CPU une fois cette opération terminée. Certains de ces systèmes nécessitent un protocole assez élaboré pour effectuer de telles opérations, certains ont des instructions spéciales pour effectuer une telle tâche, et certains surveillent même certaines adresses de "mémoire de données" et déclenchent la prise de contrôle / libération lorsqu'une tentative est faite pour y accéder . Un aspect clé de ces systèmes est qu'il existe des zones de mémoire explicitement définies pour le "code" et les "données"; même s'il est possible pour le CPU de lire et d'écrire l'espace "code", il est toujours reconnu comme étant sémantiquement différent de l'espace de données. '
Une approche alternative qui est utilisée dans certains systèmes haut de gamme consiste à avoir un contrôleur avec deux bus mémoire, un pour le code et un pour les données, tous deux connectés à une unité d'arbitrage de mémoire. Cette unité est à son tour connectée à divers sous-systèmes de mémoire à l'aide d'un bus de mémoire distinct pour chacun. Un accès par code à un sous-système de mémoire peut être traité simultanément avec un accès aux données à un autre; ce n'est que si le code et les données tentent d'accéder simultanément au même sous-système que l'un ou l'autre devra attendre.
Sur les systèmes qui utilisent cette approche, les parties non critiques des performances d'un programme peuvent simplement ignorer les frontières entre les sous-systèmes de mémoire. Si le code et les données se trouvent dans le même sous-système de mémoire, les choses ne fonctionneront pas aussi vite que si elles se trouvaient dans des sous-systèmes séparés, mais pour de nombreuses parties d'un programme typique, cela n'aura pas d'importance. Dans un système typique, il y aura une petite partie du code où les performances comptent vraiment, et il ne fonctionnera que sur une petite partie des données détenues par le système. Si l'on avait un système avec 16 Ko de RAM divisé en deux partitions de 8 Ko, on pourrait utiliser des instructions de l'éditeur de liens pour s'assurer que le code critique pour les performances se trouvait près du début de l'espace mémoire global et que les données critiques pour les performances étaient proches de la fin. Si la taille globale du code atteint par exemple 9K, le code dans le dernier 1K s'exécuterait plus lentement que le code placé ailleurs, mais ce code ne serait pas critique en termes de performances. De même, si le code n'était par exemple que de 6 Ko, mais que les données atteignaient 9 Ko, l'accès au 1 Ko de données le plus bas serait lent, mais si les données essentielles aux performances étaient situées ailleurs, cela ne poserait pas de problème.
Notez que si les performances seraient optimales si le code était inférieur à 8K et les données inférieures à 8K, la conception du système de mémoire susmentionnée n'imposerait aucune partition stricte entre le code et l'espace de données. Si un programme n'a besoin que de 1K de données, le code peut atteindre 15K. Si elle n'a besoin que de 2 Ko de code, les données pourraient atteindre 14 Ko. Beaucoup plus polyvalent que d'avoir une zone 8K juste pour le code et une zone 8K juste pour les données.