Petitverse

SPHITRCを使って、白い点の周囲の適当な大きさの矩形領域内にある緑の点を抽出し、抽出された緑の点についてのみ、距離を計算するようにすれば、処理が重くなるのをある程度防げると思います。

3DSの上画面内に、多数の緑の点が、星空のようにランダムに配置されている様子を想像して間違いないでしょうか？
だとすれば、緑の点はGPSETを使ってグラフィックレイヤーに描画しておき、白い点を起点として、GSPOITを使って、白い点の周囲のグラフィックレイヤーを、渦巻き状に走査して行き、最初に検出された緑の点を、最近傍点と判定する方法が考えられます。
このとき注意すべきは、GSPOITを渦巻き状に走査するときに、重複や抜けがないようにすることですが、このための最適なアルゴリズムは、今すっとは思いつきません。恐縮です。

ちょっと自分でも気になったので、お試し版を作ってみました。可能であれば「WJVYQ3HJ」をダウンロードしてみていただけますでしょうか。
本プログラムは、先ほど説明した渦巻き状走査方式に基づいており、白い点の周囲512画素分の円形領域を、内側から渦巻き状に、抜けや重複なく走査して、緑の点を探索します。
本プログラムを実行すると、緑の点を1000個、白い点を16個描画し、それぞれの白い点の最近傍にある緑の点を赤く着色します。左上に表示される数字は、全ての白い点に対する最近傍点の探索にかかる時間[msec]です。私の環境（旧3DS）で試すと、ばらつきはあるものの、最短でも40msec（2~3フレーム）掛かっており、処理落ちしないようにするのは難しそうです。
白い点の数が少ないほど、当然、処理速度は速くなりますし、また、渦巻き状走査方式は、緑の点を検出した時点で走査をスキップするので、緑の点の密度が高いほど（＝緑の点の数が多いほど）処理速度が速くなります。
本プログラムの2行目のNとMが、それぞれ緑の点の数と白い点の数ですので、いろいろ変えてお試しください。