> forgot to mention, it happens also when using the empty.html freshly > downloaded. (that's as far as my debugging talents go, alas..)
When using an empty.html and the built-in importer, the only overhead that could be caused by loading a remote document would be due to server response time, file size and transfer rate, because the plugins, scripts, etc in that document are simply being read in as *tiddler data* and are not invoked in any way. Of course, when you directly view the document on-line, the same server-induced transmission delays can still be present... *and* the document's plugins, script, etc. *are* also invoked... so the startup time should, in theory, be at least the same as, if not longer than, the overhead when importing. One technical difference between the two methods that might account for *some* difference in the response time: the importer uses the browser's XMLHttpRequest() function to fetch the file via javascript, while viewing the hosted document directly by entering a URL uses the browser's regular http: protocol handler. Thus, it's possible that the XMLHttpRequest() handling has other processing overhead that isn't part of the direct URL handling. In any case, while I don't doubt your observations, based on the symptoms you described it seems very unlikely that any code TiddlyTools.com could be creating the delays you are reporting. Nonetheless, I will try some timing experiments to see if I can spot a pattern and deduce a possible cause. -e --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/TiddlyWiki?hl=en -~----------~----~----~----~------~----~------~--~---
