Re: SixPacks mods for GCIC users

--- In [email protected], "Rocky" <rocsystems@...> wrote:
>
> Dave – Paolo – Gregg - ALL
> 
>  
> 
> You definitely hit on a problem.
> 
> I am well aware of the issue but I still  think 65 seconds for three
> thousand lines is extremel. Probably a another problem as well.
> 
> Even with the ineffecieent getmain logic.
> 
>  
> 
> Actually that's not a real GETMAIN –
> 
>  
> 
> Remember that GCIC is/was designed to be a Multi-user application. And as
> such storgae control was a real issue for me.
> 
> Design and reality are quite different it turns out.
> 
>  
> 
> Right at the start of GCIC it does a real getmain of a large chunk of
> storage – Module GSVC, and then all the other GETMAINS are just assiging and
> releasing pieces of that large chunk. 
> 
> In the maclib you have a GETMAIN macro which is not the real one, but which
> calls internal routines, and a GETSTRG macro which is the real getmain
> macro.
> 
>  
> 
> Since there are so many getmains and freemains in the logic I decided I
> could handle them more effeciently if I did it with my own routines.
> 
> And since this is only a 16M machine and  the application is designed to
> support multiple users ( I have had it working with 30 simultaneously – Not
> the editor, but the real application I based it on)
> 
> I was very careful about storage consumption.
> 
>  
> 
> I applied the same logic to the editor on each GET of a record  I did a
> separate GETMAIN and when freeing up I did a separate FREEMAIN. (my
> routines)
> 
>  
> 
> In my private storage table I have the length of each chunk of a storage
> acquired and the subtask id ,
> 
> As I remember it, my freemain routine does not look at the length supplied
> on the MACRO it looks at the address and the user subtask id
> 
>  
> 
> If the user issuing the freemain comes from the same subtask that acquired
> the storage and the SAME ADDRESS as a previous acquire then the whole Chunk
> is deleted.
> 
> If not, nothing happens. No RC.
> 
>  
> 
> There are several places in the file logic where individual records are
> deleted and added.
> 
> Loading a file is obviously much faster. And deletng a file also using just
> one getmain/freemain for each funtion as you are now doing.
> 
> Get enoough for the whole file in the GTABLE module.
> 
>  
> 
> But did you change the logic in the INSERT  and DELETE and COPY and PASTE
> routines as well.
> 
> Here the logic gets complicated….
> 
>  
> 
> I think that if you didn't handle this, in your new logic, if you delete the
> first record in the file, you might delete the entire file from memory with
> your logic :-)
> 
> That's just from my memory---
> 
>  
> 
> And On the other hand, when you exit a file, if you do not do it on a record
> by record basis, you might not be deleting the storage acquired for the
> records that were added individualy by COPY and INSERT and PASTE..
> 
>  
> 
> Actually when you PF3 out of the task completely all the storage acquired by
> that subtask is deleted. 
> 
> Then a DIAL into the task again again should not find.and residual storage.
> 
>  
> 
> My experience on my Windows box (fast box but not special) – is that for a
> file of 2000 – 3000 records they load rather quickly – not fast – but not 65
> seconds either.
> 
> Loading a large dump can take a half a minute.
> 
>  
> 
> Loading a normal assembler program – a second or two.
> 
> That was my trade off for keeping the logic a little simpler.
> 
>  
> 
> But I agree with you that it can be annoying if you want to look at a
> listing.
> 
>  
> 
> I like your routine and idea, but it will need a lot of refining..
> 
> We have an issue of REUSING STORAGE IN THE SAME TASK.
> 
> If you load a large file of 10000 records and then do a delete of  records 1
> to  5000 how are you going to free up that storage?
> 
> For the same task I mean 
> 
>  
> 
> If you don't free it up and then do ADD – COPY PASTE wlll need  more storage
> (how do we handle that)?
> 
> A series of DELETES and ADDS or PASTES will eventually finish all the
> storage while in reality you might only need the original 10000 lines.
> 
>  
> 
> I think its more complicated then just doing the one large GETMAIN in the
> GTABLE module.
> 
> But I'd like to make it faster – So if you want to continue this discussion
> I will be happty to get involved.
> 
>  
> 
> Anyway glad to see that someone is actually using it
> 
>  
> 
> Rocky
> 

Hi Roc,

glad to see you here again!

As I pointed the 65 secs wait in BROWSING a 3,742 lines file is mainly caused :

1)- by a slow (for our times - but equivalent to a speedy 4341-2)
    'mainframe'
2) by the 3,742 GETMAIN issued by GTABLE READFILE routine.

BTW today I managed to have a even slower perfomance: on a NETGEAR READYNAS DUO (based on a SPARC processor) I got a surprising 96 sec wait time (equivalent to about 0.67 MIPS).

My mod is (as I said) quick and dirty - just to see which performances
I could have with only one GETMAIN; but it works (3 secs versus 65).

Everything in EDIT is working fine - copy - delete - etc (even deleting first record...:-)

I didn't modify in any way your logic of chaining records; what I did
required no more than 15 assembler instructions in GTABLE routine.

I understand your issues about deleting lots of records without freeing the storage; but a first step (very easy) could be to have two READFILE routines: one for BROWSE (with my mods) and one for EDIT (with original GETMAIN logic). 

Regards.

Paul