Confirmed with
AOO410m1(Build:9750)  -  Rev. 1571426
2014-02-25_04:10:58 - Rev. 1571555
Debian

Additional info:
----------------
(a) Seems not to be related to "linked" I see the same problems after I 
    have unlinked the .svg
(b) Already Reproducible with 
  * "AOO 4.0.1 Release – German UI / German locale [AOO401m5(Build:9714)  -  
    Rev. 1524958 2013-09-20 11:40:29]" on German WIN7 Home Premium (64bit)", 
    “historic” 4.0 User Profile used for all predecessor versions	
  * server installation of "AOO 3.4.0 – German UI / German locale 
    [AOO340m1(Build:9590) - Rev.1327774]" on German WIN7 Home Premium (64bit)", 
    own separate user profile
(c) Was ok with OOo 3.3.0.
(d) LibO 4.2.1 also affected
(e) Same problems with that .svg in Writer

The unusual thing about that SVG is that it uses 146 clip-path definitions, it looks as if every single graphic component is clipped against the world. This means that for every repaint all this 146 clip regions have to be set up and clipping is an expensive operation.
I have experimentally taken out all 146 clip usages from the file and it looks exactly the same, being much faster in handling (as fast as expected). I would suggest that software creating SVG should only create clip regions which are really needed (which are actually clipping something).
The 2nd possibility is to check all clip regions to be applied at SVG import if they actually clip something at all, but this is a 2nd level approach and will increasle SVG import fore evervone; avoiding creating unnecessary clip actions initially would of course be much better and would create smaller, more effective SVG files, too.
Nonetheless all is interpreted correctly and the SVG is a correct SVG, too. For AOO rendering/cost of clipping may get less with system-dependent renderers in the future.

So we have three aspects:
- Supefluous clip-path statements which (obviously) clip nothing -> should not be created
- Possibility to detect these at SVG import and to not apply them -> will increase SVG import time for everyone
- Possibility to speedup clip region operations -> possible in the future

I am not sure what to do here. Even when opening the orig and my modded test version in FireFox you can see a remarkable slowdown with the original. The GeoGebra developers should be noted to create only needed clip regions.

@Regina: Do you have contact to that guys, or can you check if their SVG creation evtl. has options to not create clip-path's for every graphic element by default which always seem to include the whole graphic?

I took a look again and thought more about optimizing ClipRegions at SVG import time.

@Regina: When checking the graphic again (break after import) I also saw that the grid lines left and top are created twice/double; another hint to the developers if you can contact them.

First check is if the ClipRegion is a rectangle; if no, processing would get expensive but would still be possible writing a primitive processor which detects complete inside/outside. For now, do not optimize no-rectangular ClipRegion.
We have three cases when rectangular (empty is already excluded):

(a) completely outside
(b) completely inside
(c) overlap

where (c) is !a && !b. We can

(a) -> do not create content at all, all is clipped
(b) -> no ClipRegion needed, just create content
(c) -> no change, create clipped content

It showed that (b) should happen often for this concrete case since all content is clipped against the whole diagram area, but it does not. Reason is that the grid lines are '1' unit wide and that getting the range from that primitive works by getting the range from the PolyPolygon (a line in this case) and grows it by 1/2 LineWidth, so the result range is bigger than the ClipRegion and this is correct. I thought about changing this to real geometry creation fallback, but that would be too expensive. I also thought about not expanding in all directions, but this would be a big exception handling for getting the range from a polygon primitive (exceptions only for hor/ver lines, only when line, ...).
Thus, (c) happens more often than intended. That brought me to the idea to not use the original ClipRegion for (c), but that there is the chance to optimize the ClipRegion by changin git to the common range used by ClipRegion and content (intersection). This works well and creates minimal ClipRegions, the result still has some but behaves much faster. This is because the expensive part is the unnecessary size of the ClipRegions used.
It also shows that to completely avoid this it would be necessary that the authors of the software creating this stuff rethink about creating more minimal SVG files. As explained, in this concrete example not a single one of the 146 ClipRegions is needed.

Re-checking with some other stuff, also thinking about the possibility to optimize the used ClipRegion in the Paint mechanism itself in that way...

Checked with various example files, looks good. Preparing commit...

Okay, done.

"alg" committed SVN revision 1582684 into trunk:
i124313 At SVG import, try to optimize used CLipRegions

Verified on AOO420m1(Build:9800)  -  Rev. 1614365