Thank you, William!

Your explanation makes sense to me.

The first paragraph in your reply explained why
ActiveXObject calls for Excel in Curl is slower than VB
does, and this is the most important information for me.

As for the Curl codes itself, there are much things to do
for us to make the codes more efficient. 
Because the VB2Curl converter is written by a Java
programmer who is not so familiar with Curl, and also
becuase we need to sacrifice some efficiency to simplify
the converter itself, the Curl codes generated from this
converter need to be tuned, as you pointed out.

Your advice will help us greatly.

I also confirmed that setting values of each cell by
calling Cells property in Excel could be accelerated by
saving values into a String and then paste it to a Range
using Excel's Paste command by only one time.

Thank you very much.


--- William Bardwell <[EMAIL PROTECTED]> wrote:

> There are some differences in how the Curl RTE does
> COM calls,
> Visual Basic uses the COM types and COM methods
> directly, where
> the ActiveXObject class uses IDispatch::Invoke. 
> This means that
> the ActiveXObject class is doing more work
> converting things to
> and from VARIANTs as well as the COM code has to
> look up methods.
> Also depending on how the ActiveX code in Excel is
> written, if it
> returns new IUnknowns each time an object is
> requested that will
> slow things down because the Curl RTE ends up
> needing to re-lookup
> what methods and properties it has.
> So, while the Curl language code probably can not be
> as fast as
> the VB code, there are several things that you can
> do to speed up
> your code.
> 1) Save intermediate values that are reused, in
> particular in your sample
> {self.w_typRD.get-value self.w_lngRDCount} is done
> lots and lots of times,
> save that value in a variable and use that variable.
>  Similarly for each
> field you fetch it once to compare and once to save
> it, save that in
> a variable.
> 2) Use ActiveXObject as the type for any object that
> is an ActiveXObject.
> This will avoid the overhead of 'any' calls.  (So
> change:
>       {let with-1:any = self.xlSheetReport}
> to be 
>       let with-1:ActiveXObject = self.xlSheetReport
> And I suspect although I am not sure that you should
> be doing:
>     let rd-value:ActiveXObject =
>         {self.w_typRD.get-value self.w_lngRDCount}
> asa ActiveXObject
> (assuming that that is an ActiveXObject.)
> I suspect that this stuff could be optimized, to not
> be doing those
> conversions:
> {Variant-to-Boolean {vb-var-diff ...}}
> but I am not sure what it is doing, so I am not sure
> if that is true.
> If those values are just strings or integers or some
> such then you can
> just compare them in the Curl language code.  And in
> any case you could
> probably skip using Variants some how.
> This is also strange:
>        {set {with-1.Cells self.w_lngRDLine,
> 10}.Value = {{proc {}:String 
>          let byref-1:{FastArray-of String} =
> {{FastArray-of String} {self.w_typRD.get-value 
> self.w_lngRDCount}.KAISHI_YMD}
>          let ret:String = {substrDateChange byref-1,
> {{FastArray-of String} "g#e.#m.#d"}}
>          {set {self.w_typRD.get-value 
> self.w_lngRDCount}.KAISHI_YMD = byref-1[0]}
>          {return ret}}}}
> You can just use {value} instead of an inline proc. 
> And you can
> use Pointer-to or Reference-to (if on 6.0) instead
> of the FastArray-of.
> But it also looks like you don't need a to do any of
> that stuff by
> reference, you can just return two values from
> {substrDateChange}.  And
> the second argument for substrDateChange doesn't
> look like it needs to
> be by reference in any case.
> So you could have something like:
>     let rd-value:ActiveXObject =
>         {self.w_typRD.get-value  self.w_lngRDCount}
> asa ActiveXObject
>     set {with-1.Cells self.w_lngRDLine, 10}.Value =
>         {value
>             let (ret:String, replacement-ymd:String)
> =
>                 {substrDateChange
> rd-value.KAISHI_YMD, "g#e.#m.#d"}
>             set rd-value.KAISHI_YMD =
> replacement-ymd
>             ret
>         }
> William Bardwell

Reply via email to