184
edits
JSFileApi: Difference between revisions
→Problems addressed by this API: more details on problems addressed
(→Interfaces: -isExecutable) |
(→Problems addressed by this API: more details on problems addressed) |
||
| Line 5: | Line 5: | ||
''Conventions'' By the way, this document uses the conventions of [http://code.google.com/closure/compiler/docs/js-for-compiler.html|the Google Closure Compiler] for type annotations. | ''Conventions'' By the way, this document uses the conventions of [http://code.google.com/closure/compiler/docs/js-for-compiler.html|the Google Closure Compiler] for type annotations. | ||
= Problems addressed by this API = | = Problems addressed by this API = | ||
The current API for file management is based on <tt>nsIFile</tt> and its various <tt>nsLocalFile*</tt> implementations. Several performance-related concerns have surfaced wrt the <tt>nsIFile</tt> API: | The current API for file management is based on <tt>nsIFile</tt> and its various <tt>nsLocalFile*</tt> implementations. Several performance-related concerns have surfaced wrt the <tt>nsIFile</tt> API: | ||
Note: Do we know how expensive the XPCom/XPConnect overhead is, by opposition to js-ctypes and JSAPI? | *the internal implementation is based on <tt>string</tt> paths, rather than file descriptors, which in turn causes repeated filename lookups during the execution of any non-trivial sequence of operations; | ||
*it causes numerous expensive calls to <tt>stat</tt>, both when traversing a directory and when a user is interested in several properties of a file; | |||
*input/output streams do not play too nicely with JavaScript. | |||
Note: Do we know how expensive the XPCom/XPConnect overhead is, by opposition to js-ctypes and JSAPI? | |||
The present proposal attempts to address these points as follows: | The present proposal attempts to address these points as follows: | ||
*it attempts to minimize filename lookups by using file/directory descriptors wherever possible; | |||
traversing a directory; | *it attempts to minimize calls to <tt>stat</tt>, in particular when traversing a directory; | ||
*input/output attempts to play much more nicely with JavaScript, by using JavaScript low-level data structures designed for this task (and which didn't exist when the nsIFile API was designed). | |||
= Problems not addressed by this API = | = Problems not addressed by this API = | ||