I think a first good step would be to turn on the frontend analysis, and figure out which sensors are taking the longest.
Could you try to look at the time information in the analysis console?
For example:
# if you have saved your scanner logs in an analyze.log file
$ grep 'time=' analyze.log
...
INFO: Sensor JavaSquidSensor [java] (done) | time=210234ms
INFO: Sensor CSS Rules [cssfamily] (done) | time=3ms
INFO: Sensor C# Properties [csharp] (done) | time=0ms
INFO: Sensor SurefireSensor [java] (done) | time=0ms
INFO: Sensor JavaXmlSensor [java] (done) | time=16ms
INFO: Sensor HTML [web] (done) | time=4ms
...
In your case, you could probably filter by time with at least 6 digits:
$ grep -E 'time=[0-9]{6,}ms' analyze.log
Then if the analysis stays more than 10 seconds on a file, you can have duplicated lines like:
$ grep -E 'files analyzed, current file:' analyze.log
...
INFO: 1931/5345 files analyzed, current file: src/javax/xml/catalog/GroupEntry.java
INFO: 1931/5345 files analyzed, current file: src/javax/xml/catalog/GroupEntry.java
...
You can find them using:
$ diff <(grep -E 'files analyzed, current file:' analyze.log|sort) <(grep -E 'files analyzed, current file:' analyze.log|sort -u)
< INFO: 1931/5345 files analyzed, current file: src/javax/xml/catalog/GroupEntry.java
Could you share your bigger ‘time=’ log line?