On Fri, May 8, 2009 at 8:53 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > Ųyvind Harboe wrote: >>> >>> You can add your stuff for testing, ok no problem. You can put things in >>> plase so that I can test and profile potential changes. But you are >>> stepping on my toes by changing things I work on. >>> >> >> Let me take this oportunity to thank you for finding and reporting these >> bugs >> in a productive manner even if you disagree with me on this one. I believe >> I will win you over, eventually. >> >> I'm jumping to fix the problems that I've created, this includes >> performance >> problems. >> >> >>> >>> The in_handlers are not depreciated, you are suggeting that they should >>> be. >>> a big difference, and I think they should stay. >>> >> >> in_handlers cause various problems: >> >> - API bloat. It is only used in a few places. >> > > Important places :)
Right. But it complicates all the other places. >> - performance problems on embedded targets. Lots of fn calls and overhead >> in the drivers. >> > > If the operation performed by the inhandler is necessary the it must be > called anyway somwhere, it is just moved around. But if called from the calling code, it will not be a series of function calls within function calls within function calls. It will just be a loop that manipulates an array. For *slow* CPUs arm7/9 type embedded hosts, this matters. >> - hard to read code (callbacks are much more opaque than a straightforward >> manipulation in the code) >> > > We have event_callbacks, timed callbacks and other fancy stuff. Shall they > also be removed ? I don't see a strong analogy to this case so it is hard to comment. > The in_handlers are actually easier to know exactly when and how they are > called. >> >> - I believe that they will *hide* some performance problems that will >> now be brought into bright daylight. Using a normal out/in scan + >> post processing will be much clearer and faster. >> >> > > You may be right about this on embedded openocd hosts (zylin) but for > systems with long roundtrips, no ! > > The actual implementation can be check and perhaps improved. If this causes performance regressions on USB, I've promised to fix them. Some way or another. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
