RE: Re: SixPacks mods for GCIC users
"Rocky" <[email protected]> Sun, 7 Nov 2010 13:57:03 +0200
| Newsgroups | gmane.comp.emulators.hercules390.vm |
|---|---|
| Message-ID | <!&!AAAAAAAAAAAYAAAAAAAAAB8bFxJnCTpLp8w/[email protected]> |
Paolo thanks for testing
You originally wrote:
> >> I suspected that the poor performances were related to all
> >> these GETMAINs, so I tried a quick and dirty correction:
> >> I acquired an unique area of 500k at the beginning of the routine
> >> and modified the code to cope with this unique area.
> >>
> >> I got a response time of 3 sec (instead of 65) and exiting
> >> from BROWSE or EDIT is almost immediate.
You say that the response time is NOW 28 seconds instead of 65 but the path
length is reduced from 60K to 10K
I added three instructions (MVI.MVC,Store) on every getmain to prevent a
loop of thousands of ( LA and C and CLC and BR)
The path length shows that I succeeded with that.
Hard to work with responses times without understanding your environment.
I would immediatly suspect "IO" but you say that you got a responses of 3
seconds with the routine that did one GETMAIN.
I think I need more information because that doesn't make sense to me yet.
Not saying it's wrong just that I don't understand why.
If we reduced the instruction path by 80% then the rest is a constant.
Of course its going to take more time than your routine with ONE GETMAIN.
Like to know what the instruction path was for your routine with the one
GETMAIN.
I'd Like to know how much the path reduced by. That way I would have an idea
of how much the GETMAIN is taking Relative to the other stuff in the load of
a file.
Possibly this has something to do with the hardware.
Perhaps the hardware is allocating storage to Hercules etc. etc.
Maybe this last test was the first time you got storage and something
special happens.
Let me Know --- As you say I would expect a corresponding reduction.
On my box - the Dimension 9200 thats about what I got. From around 60
seconds to around 6. Asctually the first time I did it I think it was
slightly slower maybe the developers have an idea about that.
Roc
><rocsystems@...> wrote:
>>
>>
>> Hi Paolo
>>
>> This is in reply to your original problem with GCIC - slow loading of
>large
>> files.
>> I took a look at the code and "lo and behold" I have a BUG in my
>"Efficient
>> Storage handling" routines.
>>
>> Your numbers didn't make sense to me.
>> the logic.
>>
>> I took a look at my storage handling routines and found a logic bug.
>>
>> I fixed the bug with about 6 instructions and now on my dimension 9200
>the
>> same file that took 60 seconds to load - loads in about 3. (17000 records
>of
>> 132 pos.) That seems to be a fair response time.
>>
>> Rocky
>>
>
>Hi Roc,
>done a quick test on my ARM test NAS.
>
>Path length reduced from 60M to 10M:
>I'd expect a correspondent reduction of wait time (in the order of 10
>sec), but I got a time of 18.5 secs (MIPS decreased from 0.98 to 0.55
>- perhaps you introduced some heavy instruction ?-)
>
>Anyhow a good improvement; I'm going to test it on other platforms.
>
>I'm going out with my wife - BFN ;-)
>
>Paul
>
>
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/H390-VM/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/H390-VM/join
(Yahoo! ID required)
<*> To change settings via email:
[email protected]
[email protected]
<*> To unsubscribe from this group, send an email to:
[email protected]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/