1. The delay is unavoidable. Path finding can take a while.
There are other methods but they depend on what you want to do.
A* (a star) is what the pathfinding behavior uses and is the general purpose solution for simply finding a path as fast as possible. The "turning" can probably be avoided by doing the motion manually using the path points the behavior gives. If you roll your own with events then you could do things to make the delay shorter by exploiting the design of your levels.
Like say your game consists of rooms then you could do a lower resolution search of just the path from room to room and then find a more detailed path for each room you move through. And on that note you might be able to do a progressive pathfind by doing a search on a coarse grid first and then perhaps using progressively finer grids.
Also as a note, if you roll your own you could also use something besides a grid, like line segments for pathfinding to reduce the number of nodes to search through.
Dijkstra's algorithm is another, which is slower but gives you the path from all grid cells to one or more points. It basically is a flood fill that starts at the destination then expands to the neighboring cells and stores the direction to move to get to the beginning cell. This is repeated until all the cells are visited. Then the moving sprites just need to use the direction of the cell they are currently on to know which way to move. Basically the path is only calculated once.
I have an example here:
For completely delay free pathfinding you could pre-calculate the path from every point to every other point.
This guy did just that:
The disadvantage is it's tedious to setup, but once it is the pathfinding will take no time at all. The cells are pretty big, but the idea is to just get the enemies in the general area and then use something simpler to move toward the player's exact position.