DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=30442>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=30442 How to make slide faster - submission ------- Additional Comments From [EMAIL PROTECTED] 2004-08-05 21:05 ------- It seems to me like we should have a basic update statement that would work for any RDBMS, then extend that for specific versions if there is a more efficient way to do it. Concerning speed improvement: Yes, my proppatch really does take an average of about 25 milliseconds for the whole webdav request. Some took a little longer, some took a little less. These results are after the revisiondescriptor has been cached and slide is writing to a mysql database on the local machine. It does take longer if the revisiondescriptor hasn't been cached yet, but for consistency I used the timings from runs after it had been cached. I was using a test client (also on local machine) which does multiple webdav requests, but I also tried a manual proppatch through the command line webdav client and saw similar times. My statements for timing were in the client code both times. I'm pretty sure that the proppatch is performing correctly because the property is being added/changed and when I watch the requests and responses on the network they are all going through. What kind of times were you expecting to see? I agree that we should definitely optimize inside the slide kernel and webdav layer as well, but shouldn't we cut down in all areas we can? It doesn't make sense to me to rewrite properties/bindings that haven't been modified. If we optimize on the both sides we should get even more improvement. Tara --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
