64bit対応で高速化が期待できる
Cortex-A35は、Cortex-A7などと同じくインオーダー（命令を順序通りに実行する）でデコーダーで2命令を同時に発行することができる。パイプラインは8ステージでロードストアと整数演算、NEON命令は別のパイプラインとなっている。
Cortex-A35の内部パイプライン。命令を順序通りに実行する「インオーダー」構成で、8ステージのパイプラインとなる。命令デコーダーは、制限付きながら2命令の発行が可能
ただし、同時に実行できるのは、整数演算とロードストア、またはNEON命令と組み合わせが限られ、すべての場合に2命令を同時実行できるわけはない。このため、単純て整数演算などでは、Cortex-A7とCortex-A35はあまり大きな性能差がない。
Cortex-A35とCortex-A7のパフォーマンス比較。整数演算では6%しか差がないが、データアクセスや浮動小数点のSIMD演算を多用すると性能差が出てくる
しかし、データアクセスにプリフェッチ機能があり、連続した領域のデータアクセスなどが効率良くできるようになっている。もう1つは、L1とL2が改良されて、性能が高くなっている。このため、メモリアクセスだけを見ると、Cortex-A35は、Cortex-A7の3.75倍の性能があるのだという。
性能差の理由の1つは、L1、L2の性能向上やデータのプリフェッチ機能などだ。この部分だけを見ると最大で3.75倍の性能差がある
こうしたアーキテクチャ上の工夫で、同じ製造プロセスで作っても、ウェブブラウジングのベンチマークでCortex-A7（同じくインオーダーコア）より16％ほど高速化している。
同じ28nmプロセスで製造したとき、Cortex-A35は、ウェブブラウジングで比較するとCortex-A7の1.84倍の性能が出せる。ただし、Cortex-A35は28nmプロセスで高性能な実装を行なっているため、クロック周波数も高くなる。しかし、クロック比では約1.7倍（2GHz÷1.2GHz）でアーキテクチャの違いによる性能差もある
また、同じコードで比較した場合だが、AMRv8の場合、ソフトウェアが64bit対応していると、同等の機能であっても、高速化されることが少なくない。というのも64bit命令のほうが高機能な暗号化命令などに対応しているからだ。
また、NEONの仕様も64bitでは拡張されているため、64bitコード化することで高速化することがある。同じ32bit環境でも、ARMv8の32bit環境（AArch32）では、拡張されている部分があり、64bit環境と同じ暗号化処理命令が利用可能など、高速化する余地がある（写真10#%P10%#）。同じクロック周波数でも暗号化処理などでは、3.5～11倍という速度差が生まれる（写真11#%P11%#）。
ARMv8-Aは、ARMv7互換の32bitアーキテクチャ（AArch32）と64bitアーキテクチャ（AArch64）を持っている。しかし、A35では、ARMv8で新設された暗号化命令などが利用できるように拡張されている
SHA-1（ハッシュ関数）、AES（暗号化方式）などに対応した命令セット（ARMv8で導入された）を持つため、Cortex-A7と比較すると性能差が大きくなる
ただし、どちらの場合も既存のソフトウェアを64bit化やARMv8対応する必要がある。比較的更新頻度の高いソフトウェアであれば、高速化が期待できる。なお、Androidの場合、アプリケーションはJavaの仮想マシンコードで記述されるため、アーキテクチャには影響されにくい。
しかし、これを実行するJava仮想マシン（VM）自体が高速化すれば、アプリケーションも高速化される可能性がある。また、一部のアプリでは高速な処理を行なうために機械語コードのモジュールを組み込んでいるものがある。それならば、この部分だけを64bit対応などにすることでさらに高速化される可能性がある。
Cortex-A35は、現在Cortex-A7を使うような低価格スマートフォン向けに利用可能で、さらにスマートウォッチなどのハイエンドなウェアラブルもターゲットにしている。また、LITTLEプロセッサとして、Cortex-A72やArtemisなどのbigプロセッサとの組み合わせでハイエンドスマートフォンやタブレットに導入されるだろう。その意味では、最も重要なCortex-Aプロセッサになる可能性がある。
