Using things like PVector generally involves creating a lot of temporary objects, i.e. objects that are used once and then thrown out during the course of the draw() loop. On limited architectures, like mobile phones, this allocating and deallocating (garbage collecting) 100s or 1000s of these objects each time you go through draw() will be really expensive.

On your desktop machine, you won't notice it. On Android, you may see the garbage collector running incessantly, freeing up a few hundred kb of objects. Some of the PVector examples do this, and therefore run very slowly. I noticed this when testing some of Dan's examples with Android mode.

(As an aside, this is why we only added PVector to Processing much later, because we didn't want people to slow down their sketches by using a lot of temporary objects like this; or have to explain why it was computationally expensive.)

In the code there, it's things like the "new PVector" inside update(). I'm surprised you would see that much trouble with just one object, though. It's possible the unnecessary fill() command might be doing a bit as well, though I don't know offhand.

Also, if you aren't already, you should test on a device, not in the emulator. Emulator performance is terrible, especially if you're using a more limited machine like a netbook.

Also, you should consider using the set() function, which will work the same way but won't create a new object instance each time.