large web pages

large web pages

[Doug Evans]

To what extent should I be concerned with overtaxing sources' resources [sic]
with large web pages?  I haven't a clue what the threshold is before I 
should be concerned.  Suggestions?

-bash-2.05b$ ls -l /sourceware/www/sourceware/htdocs/cgen/gen-doc
total 3576
-rw-r--r--    1 devans   cgen           77 Jun 11 07:18 README
-rw-r--r--    1 devans   cgen       407269 Jun 11 07:18 arm-arm-insn.html
-rw-r--r--    1 devans   cgen         9786 Jun 11 07:18 arm-arm.html
-rw-r--r--    1 devans   cgen        77123 Jun 11 07:18 arm-thumb-insn.html
-rw-r--r--    1 devans   cgen        11348 Jun 11 07:18 arm-thumb.html
-rw-r--r--    1 devans   cgen      1277408 Jun 11 07:18 frv-1-insn.html
-rw-r--r--    1 devans   cgen        98544 Jun 11 07:18 frv-1.html
-rw-r--r--    1 devans   cgen       859187 Jun 11 07:18 frv-2-insn.html
-rw-r--r--    1 devans   cgen        91785 Jun 11 07:18 frv-2.html
-rw-r--r--    1 devans   cgen       353603 Jun 11 07:18 i960-insn.html
-rw-r--r--    1 devans   cgen         5778 Jun 11 07:18 i960.html
-rw-r--r--    1 devans   cgen       134595 Jun 11 07:18 m32r-insn.html
-rw-r--r--    1 devans   cgen         7621 Jun 11 07:18 m32r.html
-rw-r--r--    1 devans   cgen        66454 Jun 11 07:18 openrisc-insn.html
-rw-r--r--    1 devans   cgen         6400 Jun 11 07:18 openrisc.html
-rw-r--r--    1 devans   cgen       174755 Jun 11 07:18 xstormy16-insn.html
-rw-r--r--    1 devans   cgen         6830 Jun 11 07:18 xstormy16.html

I expect the pages to be read rarely (one might imagine a marginal
chance of a slashdot effect tomorrow, but I dunno ...).

Obviously I can (and perhaps should) split up the *-insn.html files
(or more preferably have the arm and frv ports be able to be written
more intelligently, but that's down the road).

Re: large web pages

[Ben Elliston]

Doug Evans <dje@sebabeach.org> writes:

> To what extent should I be concerned with overtaxing sources'
> resources [sic] with large web pages?  I haven't a clue what the
> threshold is before I should be concerned.  Suggestions?

They might be a little big (for various values of "big"), but they
will be almost never accessed, so I don't see a problem.  If you're
really concerned, ask overseers at sources.redhat.com.

> I expect the pages to be read rarely (one might imagine a marginal
> chance of a slashdot effect tomorrow, but I dunno ...).

I hate to rain on your parade, but I doubt it :-)

Cheers, Ben

Re: large web pages

[Doug Evans]

Ben Elliston writes:
 > > I expect the pages to be read rarely (one might imagine a marginal
 > > chance of a slashdot effect tomorrow, but I dunno ...).
 > 
 > I hate to rain on your parade, but I doubt it :-)

Agreed.  Ergo "... but I dunno ...".

Re: large web pages

[Doug Evans]

Doug Evans writes:
 > Ben Elliston writes:
 >  > > I expect the pages to be read rarely (one might imagine a marginal
 >  > > chance of a slashdot effect tomorrow, but I dunno ...).
 >  > 
 >  > I hate to rain on your parade, but I doubt it :-)
 > 
 > Agreed.  Ergo "... but I dunno ...".

i.e. you have to read that with a sarcastic inflection.

frv suggestions

[Doug Evans]

Here's a couple of suggestions for the frv port.

1) I don't know if anyone maintaining it uses emacs,
but I'd highly recommend using ^L to delimit groups of
instructions.  When skimming through source files, I find the
following extremely useful.

; one-liner describing this section

mumble ...
^L
; one-liner describing this section

mumble ...
^L
; one-liner describing this section

mumble ...

... and so on ...

If something is small enough one sometimes needn't bother.
But methinks frv.cpu is big enough that the above would be helpful.
frv.cpu already does this for hardware vs operands vs insns, etc.
But the "Instruction definitions" section is large enough that
I wonder if adding some more ^L's would make traversing it easier.
Just a thought.  I only browse it rarely, so I don't know if going
to the trouble will pay off or not.

In emacs I can then do C-x [ and C-x ] to quickly traverse through
each section of the file and with the one-liner I can quickly see where I am.

2) To make the generated html more useful, you might want to
redefine the IDOC attribute to be something more resembling the frv,
and add the attribute to each instruction.  This lets the html generator
categorize instructions and makes the instruction set more accessible
to the human reader.

I added some simple heuristics to make the result semi-usable
in the absence of explicitly provided IDOC attributes, but it breaks down,
for example, if all memory accesses are done via c-call's. :-)

It also breaks down on the arm when every alu op can set the pc.  Blech.

Re: large web pages

[Phil Edwards]

On Wed, Jun 11, 2003 at 01:08:38AM -0700, Doug Evans wrote:
> To what extent should I be concerned with overtaxing sources' resources [sic]
> with large web pages?  I haven't a clue what the threshold is before I 
> should be concerned.  Suggestions?

I have no clue either, but I will mention that a certain directory tree
on the webserver is gzip'd nightly.  If the browser indicates that it can
handle gzip'd files, that's what the server sends.  The original copy is
also kept, for the sake of less capable browsers.

For the life of me I can't recall which directory tree it is.  I think
it's everything that shows up under http://gcc.gnu.org/onlinedocs/.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: large web pages

[Doug Evans]

   Date: Wed, 11 Jun 2003 14:00:48 -0400
   From: Phil Edwards <phil@jaj.com>

   I have no clue either, but I will mention that a certain directory tree
   on the webserver is gzip'd nightly.  If the browser indicates that it can
   handle gzip'd files, that's what the server sends.  The original copy is
   also kept, for the sake of less capable browsers.

   For the life of me I can't recall which directory tree it is.  I think
   it's everything that shows up under http://gcc.gnu.org/onlinedocs/.

Jason pointed me at /www/sourceware/htdocs/gdb/onlinedocs,
and I happened to notice .gz files there.

frv-1-insn.html compresses very nicely, 1277408 -> 84001.  woohoo.
With a fast connection and a fast machine there's no significant
difference to page loading speed though.
People with slow connections would presumably notice of course.

Re: large web pages

[Jason Molenda]

On Wed, Jun 11, 2003 at 02:00:48PM -0400, Phil Edwards wrote:

> I have no clue either, but I will mention that a certain directory tree
> on the webserver is gzip'd nightly.  If the browser indicates that it can
> handle gzip'd files, that's what the server sends.  The original copy is
> also kept, for the sake of less capable browsers.


We did this with a nonstandard apache module with 1.x; I'm pretty
sure the functionality was lost in the Apache 2 upgrade.  There is
a way to do the comparable thing at run-time with Apache 2, but it
takes some configuration changes.  I had the necessary changes figured
out a while back but I don't remember them right now.

I liked the static .gz files because so little of our content is
dynamic -- no reason to compute that stuff on the fly.

All the mainstream browsers can handle inline gzipped content these
days, BTW.  The trick to seeing the difference is to either watch
the Apache log.  Or most browsers have a progress bar that shows
the amount of data transferred so far -- if you're downloading a
big doc page or one of the completed mailing list web archive dirs
(all the indexes are compressed), you can see the number of bytes
being transferred.  It's pretty obvious; if you bring up
gcc.gnu.org/ml/gcc/2003-06/ you'll download over two hundred kb --
gcc.gnu.org/ml/gcc/2003-05/ is only 53kb if the .gz file is sent.


Anyway, one of these days one of us will get around to re-enabling
this stuff.

J