[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::sql

Title:	SQL notes

Moderator:	NOVA::SMITHI

Created:	Wed Aug 27 1986
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3895
Total number of notes:	17726

3891.0. "SQLPRE Taking a Long Time with /DEBUG" by M5::BLEHLBAC (RDB: 34% better than real life) Thu May 29 1997 12:28

Hi,

  Rdb 7.0-eco1

  I have a customer who has noticed an increase in runtime when precompiling
a 28,000 line C program.  The time increase occurs when the /DEBUG qualifier
is used.  When /DEBUG is used the precompile time is about 11 minutes, while
when it is not specified the precompile time is under 2 minutes.  The user
checked the "Run Time" and "Elapsed Time" on the listing, and it shows that
the time is spent in the precompile phase.  The C compile phase appears to
about 30 seconds (if I'm looking at things correctly).

  I ran a test on a small C program and didn't notice a significant
difference in the times when using and not using /DEBUG.

  Following are the symbols and command lines used.  The ""CC" command
line is run first and then the "SCC" command line.

  I thought a problem might be the "CC" is a symbol as well as a qualifier,
but the customer deassigned the symbol "CC" and the behavior appeared to be
the same as when it was assigned.

  Any ideas as to what is causing the increase in time??

                             Thanks,  Barry

$ debug:
$   link :== link/debug
$   cc   :== cc/debug/nooptimize -
             /define=(DEBUG,FORMS_DEBUG)/STANDARD:VAXC/NOMEMBER_ALIGNMENT
$   scc  :== $sql$pre/cc/debug/nooptimize/nog_float -
             /define=(DEBUG,FORMS_DEBUG)
$!
$ nodebug:
$   link :== link/nodebug/traceback
$   cc   :== cc/nodebug/define=(nodebug)/STANDARD:VAXC/NOMEMBER_ALIGNMENT
$   scc  :== $sql$pre/cc/nodebug/nog_float/define=(nodebug)
$!
$!
$!
$	CC/NOLINE/NOWARN/INCLUDE=DMQ$USER/PREP=SIMS$SQL_PROCESS.SCP -
	SIMS$SQL_PROCESS.SC
$!
$	SCC/SQLOPTIONS=(CONNECT) SIMS$SQL_PROCESS.SCP
$!
------------------------------------------------------------------------------

T.R	Title	User	Personal Name	Date	Lines
3891.1	is this on alpha?	NOVA::HERRE		`Thu May 29 1997 13:43`	3
	If this is on alpha, a lot of symbol table and line information is kept around if /debug is used. On vax, there should not be any real difference.
3891.2		M5::JHAYTER		`Thu May 29 1997 13:56`	9
	> If this is on alpha, a lot of symbol table and line information > is kept around if /debug is used. > On vax, there should not be any real difference. not to cause a side issue, but what does sqlpre do with /debug? I thought /debug was just passed on the language compiler and the impact on sqlpre was zip.
3891.3		NOVA::HERRE		`Thu May 29 1997 14:20`	7
	> I thought /debug was just passed on the language compiler and the > impact on sqlpre was zip. I thought that too. When I looked at the code today, I noticed that some GEM flags are being set when /debug is used. On vms, it still looks like it just passes it through.
3891.4	oops. I meant on vax.	NOVA::HERRE		`Thu May 29 1997 14:22`	6
	> I thought that too. When I looked at the code today, I noticed that > some GEM flags are being set when /debug is used. On vms, it still > looks like it just passes it through. I meant to say, on vax, it still looks like it just passes it through.
3891.5		NOVA::SMITHI	Don't understate or underestimate Rdb!	`Thu May 29 1997 14:55`	6
	~The user checked the "Run Time" and "Elapsed Time" on the listing, and it ~shows that the time is spent in the precompile phase. What listing? C has its own precompile phase too. Ian
3891.6	Thanks .... any workarounds???	M5::BLEHLBAC	RDB: 34% better than real life	`Thu May 29 1997 15:09`	13
	re .1 yes, it's on an alpha, I should have mentioned that. In fact, I believe the customer said that there was no noticable time difference on the vax. Thanks .... is there any workaround to speed things up?? re .5 on the test that I ran the data in the "Statistics Summary" is identical in both the output of the precompile listing and the final C .LST file. I was under the impression that these times refer to the precompile step only.
3891.7	possible workaround	NOVA::HERRE		`Fri May 30 1997 01:20`	21
	I wouldn't really recommend this, but this might help if the customer is desperate for improved compilation time and needs to compile the .c file debug, but doesn't need the sql statements compiled /debug. First, define the logical sql$keep_prep_files. Then instead of $ SCC/SQLOPTIONS=(CONNECT) SIMS$SQL_PROCESS.SCP try $ SCC/NODEBUG/SQLOPTIONS=(CONNECT) SIMS$SQL_PROCESS.SCP $ CC/DEBUG/NOOPT SIMS$SQL_PROCESS.C $ COPY/TRUNCATE SIMS$SQL_PROCESS.OBJ, SIMS$SQL_PROCESS.MOB SIMS$SQL_PROCESS.OBJ Then, use this .obj file as you would use the one generated by sqlpre. This won't be very fast, since the .c file is being compiled twice, but if the difference in sqlpre compilation times is as great as you claim, it should speed things up.