YES!
The work-around was as follows if you want to compare:
s is a stream object so
a = s~ArrayIn
vs.
a = s~CharIn(, s~Chars)~MakeArray
The latter was MUCH faster with files of a big enough size. Many of us
have adopted the latter technique out of habit since this issue has been
around so
0.765 for trunk, 0.438 for 3.2.0. There's obviously additional
opportunity for improving this here.
Rick
On Thu, Jul 3, 2008 at 10:44 AM, Lee Peedin <[EMAIL PROTECTED]> wrote:
> Try this on both versions and see what you get:
>
> call time 'r'
> do 200
> s = .stream~new("\ORexxDev\oorexx\k
Try this on both versions and see what you get:
call time 'r'
do 200
s = .stream~new("\ORexxDev\oorexx\kernel\runtime\RexxActivation.cpp")
a = s~charin(,s~chars)~makearray
s~close
end
say time('e') "for" a~items "items"
Rick McGuire wrote:
> Ok, I took a couple minutes to do th
Ok, I took a couple minutes to do the experiment. Here's the simple
test I was using:
call time 'r'
do 200
s = .stream~new("\ORexxDev\oorexx\kernel\runtime\RexxActivation.cpp")
a = s~arrayin
s~close
end
say time('e') "for" a~items "items"
The file RexxActivation.cpp has 3995 lines...
Well, the fixes I put in helped to reduce that by reducing the number
of temporary objects that got created during processing. If the real
issue was excessive GC cycles, then I fixed that problem back about
the year 2000 before Object Rexx was even open source.
Interestingly, when I was looking a
Rick McGuire wrote:
> On Thu, Jul 3, 2008 at 9:30 AM, Gil Barmwater <[EMAIL PROTECTED]> wrote:
>
>>With all the changes to STREAM in the new release, I was wondering if
>>the performance issue with ARRAYIN has been addressed as well (I seem to
>>remember a discussion about the cause having been lo
On Thu, Jul 3, 2008 at 9:30 AM, Gil Barmwater <[EMAIL PROTECTED]> wrote:
> With all the changes to STREAM in the new release, I was wondering if
> the performance issue with ARRAYIN has been addressed as well (I seem to
> remember a discussion about the cause having been located but don't know
> if
With all the changes to STREAM in the new release, I was wondering if
the performance issue with ARRAYIN has been addressed as well (I seem to
remember a discussion about the cause having been located but don't know
if it was an easy fix or not). BTW, GREAT JOB on ALL the changes that
everyone
On Wed, Jul 2, 2008 at 5:08 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Well, if the file search is making multiple calls to SysFileTree, then
> the improved external function calling mechanism probably accounts for
> a significant portion of that.
Actually it just does 1 call to SysFileTree. I
Well, if the file search is making multiple calls to SysFileTree, then
the improved external function calling mechanism probably accounts for
a significant portion of that. All of the rexxutil functions will
benefit from that change.
Rick
On Wed, Jul 2, 2008 at 8:04 PM, Mark Miesfeld <[EMAIL PR
On Wed, Jul 2, 2008 at 3:35 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Cool! ...
> starting showing up now because the calls to native functions are now
> significantly faster than the previous release.
Speaking of significantly faster, I had meant to draw your attention this.
Take a close loo
On Wed, Jul 2, 2008 at 3:35 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Cool! I'm going to hazard a guess as to why. The clipboard access is
> done using registered native functions.
That is cool.
And, indirectly, why I thought this was a timing problem. It looked
to me like the two back to
On Wed, Jul 2, 2008 at 3:28 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 2, 2008 at 3:10 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>> Mark,
>>
>> I'm curious...is the clipboard timing problem a new problem on trunk,
>> or did it occur on 3.2.0 also? I'll explain why I'm asking once
Cool! I'm going to hazard a guess as to why. The clipboard access is
done using registered native functions. In 3.2.0, the table of
registered functions is held by the rxapi process, and every time you
make a call to a registered routine, there's an interprocess call
involved to retrieve the ent
On Wed, Jul 2, 2008 at 3:10 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> Mark,
>
> I'm curious...is the clipboard timing problem a new problem on trunk,
> or did it occur on 3.2.0 also? I'll explain why I'm asking once I
> have your answer.
I didn't see it on 3.2.0.
--
Mark Miesfeld
--
Mark,
I'm curious...is the clipboard timing problem a new problem on trunk,
or did it occur on 3.2.0 also? I'll explain why I'm asking once I
have your answer.
Rick
On Wed, Jul 2, 2008 at 5:56 PM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Wed, Jul 2, 2008 at 1:48 PM, Chip Davis <[EMAIL PROT
On Wed, Jul 2, 2008 at 1:48 PM, Chip Davis <[EMAIL PROTECTED]> wrote:
> On 6/30/08 14:48 Mark Miesfeld said:
>> The Clipboard test case that failed did a clipboard copy immediately
>> followed by a clipboard paste.
>>
>> cb1~copy("Some text")
>> text = cb2~paste
>>
>> Sometimes text would be th
On 6/30/08 14:48 Mark Miesfeld said:
> The Clipboard test case that failed did a clipboard copy immediately
> followed by a clipboard paste.
>
> cb1~copy("Some text")
> text = cb2~paste
>
> Sometimes text would be the empty string. I think that was just
> timing. If you query the clipboard
Well, the next task is to spend some time on Linux
Rick
On Mon, Jun 30, 2008 at 10:48 AM, Mark Miesfeld <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2008 at 7:38 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
>> PUBLIC_ROUTINES was that hack that oodialog was using that I
>> eliminated. I also
On Mon, Jun 30, 2008 at 7:38 AM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> PUBLIC_ROUTINES was that hack that oodialog was using that I
> eliminated. I also updated this test for the new classes that have
> been added.
>
> The monitor test failure was the same as the lines() problem, which
> shoul
PUBLIC_ROUTINES was that hack that oodialog was using that I
eliminated. I also updated this test for the new classes that have
been added.
The monitor test failure was the same as the lines() problem, which
should be fixed now.
Rick
On Sun, Jun 29, 2008 at 8:50 PM, Mark Miesfeld <[EMAIL PROTEC
Rick,
It is great! I meant to send out an e-mail earlier, but was in
a rush to get to a dinner with my mom.
I was surprised to get here this quickly also.
--
Mark Miesfeld
On Sun, Jun 29, 2008 at 5:54 PM, Rick McGuire <[EMAIL PROTECTED]> wrote:
> This is great1 I'll try to take a
This is great1 I'll try to take a look at the
lines/monitor/environment directory problems tomorrow. I seriously
did not expect that we'd reach this point this quickly, given the size
of the changes I had to make with this stage of the process.
Rick
On Sun, Jun 29, 2008 at 8:50 PM,
Well looking at them again, there is this one:
[failure] [20080629 15:29:18.905000]
Test: TEST_ENVIRONMENT_DIRECTORY_ENTRIES
Class: environmentEntries.testGroup
File: E:\work.ooRexx\...\base\runtime.objects\environmentEntries.testGroup
Line: 168
Failed: assertTrue
Expected: [1]
A
Rick,
I can run the entire suite now. There are 3 testGroup files that are
for sample programs that got skipped on my system because I still have
REXX_HOME set in my environment. I fixed that in ooTest and committed
it a little while ago.
ooDialog needs some work, but I have already started tha
Mark,
What tests need to be run yet? Are these still just being run
individually? I don't want to duplicate what you've already run.
Rick
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell
26 matches
Mail list logo
