----- Original Message -----
From: "Theodore H. Smith" <[EMAIL PROTECTED]>
I max somethings out, and leave other things "fast enough" even if that's
quite inefficient, simply because its not worth the effort.
I don't think in the case of XML, that it is possible to precalculate the
size of the string.
No, but I'm not using XML anymore. In fact, I'm not even using FolderItems.
I've created my own 'file system' if you will, which Metropolis uses to
store 'DirItems'. Retrieving a DirItem's data returns it as ElfData by
default. Even a DirItem's path is an ElfData object. That way I can perform
certain actions (like generating relative urls) much faster and without
suffering from the Operator_Convert penalty time and time again.
There's only a few places where I can't avoid Operator_Convert (like
displaying the DirItems in a listbox, but that's where it matters least, and
of course when transferring my data to RBScript, but because of all
optimisations before it, the penalty doesn't hurt there either.
For code at the 'heart' of Metropolis I never settle for 'fast enough'. I
keep fiddling and trying until I'm fairly convinced it can't be done any
faster. This attitude has set Metropolis apart from any competition, wether
open source or commercial. There's nothing that comes close, period.
I am excited about this upcoming release for all the improvements with
regard to storage, cache, toolbars and general maturity of the software.
Besides, if all you are doing is writing it to a file, I have made a cool
FastString technique in which don't even need to precalculate the file
size. If you run my Showcase app, you'll see a test "File Append". It's
the very first test.
Interesting. I could have used it for previous versions, but it doesn't
matter anymore.
There is a "ED via FastString" test. This basically appends stuff into a
binary stream, using a FastString class as an intermediatry. This one
doesn't suffer from any unnecessary buffer copying, even if you are
writing huge files (200MB or more). In fact while it is faster, it is
only 1.5x faster than my FastString class done in it's default manner,
and only then in very long strings. For strings of a few MB, the speed is
almost identical.
Really, the biggest advantage of my FastString class is not just it's
speed. It is how it makes things simple. .AppendIntegerAsText is
indispensable, as is .AppendHex.
Yes, I need not be convinced.
But even if Join is faster in certain cases, you'd still only have a string.
For Metropolis, "Join+Operator_Convert" would have to be faster than
FastString for me before I'd use it, and I don't have to test to know that
is not the case.
Understand me well, I'm no ElfData advocate per se. I'm not using it when it
doesn't make sense. Like my pre-alpha webserver that got everyone else's
beat didn't use ElfData because I could do it faster with pure RB.
Ronald Vogelaar
--
http://www.rovosoft.com
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
