[Webkit-unassigned] [Bug 48212] SVG FELighting performance issues

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=48212





--- Comment #8 from Dirk Schulze <krit at webkit.org>  2010-10-27 07:15:52 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > Thanks for taking the bother to check ByteArray, have you used callgrind (kcachegrind) or shark to look why it is slower on ByteArray? Is it the get and set method? If so, we might follow kling's suggestion and add a unsafeGet/Set method. I'd also like to know what takes most of the time after your changes.
> 
> Assembly magic. The pixels->get(offset) is turned to indexed addressing modes  [reg + reg], while the other [reg, immediate] is supported by more architectures, and results a simplified machine code.
> 
> Valgrind is not useful for performance measurements, since it totally recompiles the code, even if you don't touch the instruction stream. Valgrind is a great tool, and excellent for searching memory leaks (and other things unrealted to performance).
> 
> There is no unsafeGet method for ByteArray. Get is unsafe enough :)
> 
> unsigned char get(unsigned index) const
> {
>     ASSERT(index < m_size);
>     return m_data[index];
> }

You don't need to recompile for using callgrind, and it is very useful to see how much time is spend in which function. Valgrind is a tool chain, and consists of different tools, not only cachegrind (I guess you were just thinking about this). kcachegrind2 on the other hand is just a graphical tool and makes it quiet easy to visualize the output of callgrind.

Yes, get is pretty simple, but set has a bit more "complexity", that might get visible on the massive calls of it for pixel manipulation.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.