On Wed, Jul 30, 2008 at 7:41 AM, Michael Fischer <[EMAIL PROTECTED]> wrote: > Hello Spen, > > please add your patch if it is working. The time will > show if it is OK or not. Like with other feature before.
Lots of changes have been rejected to this code. Just becuse this is the latest change, doesn't mean that it shouldn't compete on the same terms as other performance suggestions to this code. The problem with this change is that we already know it will cause some performance regressions. It is a performance optimisation and performance optimisations should always be backed by numbers/measurements. Optimization should be 90% profiling 10% programming, generally. This is code that has already been optimized, so this change should compete with other changes to this code on the same terms: documented performance improvement. I'm not asking for reems of documentation, but *some* evidence that it is in fact faster. One idea that came to me is that packets smaller than 512 bytes or so will probably be slower. There are many small packets. The ethernet hardware has a lower limit to the packet length for ethernet, so it makes no sense to try to compress those packets. Also the operating system will have a lot of TCP/IP optimisations. -- Øyvind Harboe http://www.zylin.com/zy1000.html ARM7 ARM9 XScale Cortex JTAG debugger and flash programmer _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
