What do you mean by "manual profiling"?
There really is no substitute for a proper profiler, there's no way you could add performance counters in every method of your code. The whole point of profiling is to show you exactly where CPU time is eaten up. This is very often in a place you wouldn't think to look or could show up some simple mistake you made. Improving profiler hotspots is really the only way to improve performance, how else would you know that you've actually improved it?
Just glancing at your code, the first thing I would do is DRY it up a bit ("globalInfo->events[counter]" is repeated 15 times in about 20 lines). At least then you will have less code to look at and get more of a sense where time is being spent.
As a simple example I noticed one of my list boxes was a bit sluggish on iOS so I thought I'd improve the graphics performance a bit. Launched it with a profiler attached, scrolled the list backwards and forwards a couple of times and then reviewed the result. 50% of the time was spent drawing buttons. I realised the buttons were actually behind some opaque labels that I'd forgotten to hide. 3 buttons per row over about 20 rows made for a lot of button repaints every frame. I made them show and hide themselves when necessary and got all that CPU back, took me about 5 minutes in total. Probably wouldn't have noticed that for ages otherwise.