Re: [patch,libgfortran] PR48298 DTIO implementation for Internal Units

[Jerry DeLisle <jvdelisle at charter dot net>]

On 09/14/2016 07:19 AM, Jerry DeLisle wrote:
> On 09/14/2016 12:47 AM, Manfred Schwarb wrote:
> > Hi Jerry,
> >
> > Am 14.09.2016 um 07:56 schrieb Jerry DeLisle:
> > > Hi All,
> > >
> > > The attached patch implements the necessary changes for DTIO to/from internal
> > > units.
> > >
> > > Prior to this patch, internal unit character strings and related data were
> > > kept within the dtp structure with a pseudo unit number assigned. Since child
> > > I/O procedures need this information passed to them through the unit number,
> > > it is necessary to move this information into the gfc_unit structure.
> > >
> > > This also implies that the internal unit needs a legitimate and unique unit
> > > number. This is accomplished using the existing newunit mechanisms to obtain
> > > a unit number and then allocating the unit structure on the existing treap
> > > mechanism used for all units.  The child I/O procedures can then find the
> > > units for use.
> >
> > How does this affect performance?
> > I mean, reading and writing to/from internal units is a common thing and is
> > certainly performance critical in some cases. It is already slow as is,
> > so it would be sad to slow down this mechanism even further.
> > Does acquiring a new unit and allocating the structure impair performance?
> > Or does your stack approach mitigate this completely?
> >
> > Thanks,
> > Manfred
>
> I did think about this issue a little. Honestly have not had time to test the
> actual performance.
>
> There is a trade-off between the time to do the stack check and treap search vs
> the allocation of the unit structure.  Currently I do nothing to try to
> recognize if the same string is being used from one I/O statement to the next,
> so there is that possibility in the future...
>
> It has been my hope that this stack will avoid allocations and speed things up a
> little.  We now have something to test.

Well so much for my hopes. I have done some large loop tests with two strings 
inside the loop. One is KIND=1 and one is KIND=4.

I see a 15% slowdown.  My guess is its in the treap search and stack overhead.

The test I used:

program internal1
  implicit none
  character(kind=1, len=30)  ::  str1
  character(kind=4, len=30)  ::  str4
  integer :: i1
  integer :: i2
  integer :: i, j

  do j=1,100
    do i=1,10000
      write(str1,*) i
      write(str4,*) i + j
    end do
  end do
end program