[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: EXE Code Too Large



PureBytes Links

Trading Reference Links

Kim,
	I have written two identical versions of the same indicator.  One stores
data to and retrieves data from a multi-dimensional array in TS, the other
stores/retrieves data to/from the HashNums DLL, specifically using the
functions that store and retrieve by index number i.e. putNo("High", 1,
1080) and getNo("High",1).  I stored the "array data" in the HashNums DLL
not in a .csv file.  Otherwise the code is identical.  I processed the exact
same data i.e. a daily chart, used the exact same loop structures and
bubbled down the arrays the same way.  The HashNums version is many, many
orders of magnitude slower than the TS version on my computer (Pentium 150
MHz, 512 KB cache, 128 MB RAM in Win95).  It's so slow that I wouldn't even
attempt it on a real-time chart.  The only problem with the TS version is
the 64K limit which prevents me from adding everything I want.

	If however you have any insight into interfacing HashNums with VB so that
data could be passed from TS to HashNums, processed in VB, returned to
HashNums and imported back into TS then I'd be interested in learning how.
There are several programming hurdles that need to be overcome to do this.
The HashNums on-line manual is very ambiguous on this matter.

Sincerley,
Mark.
> -----Original Message-----
> From: Kim Horn [mailto:kim@xxxxxxxxxx]
> Sent: Thursday, September 17, 1998 2:14 AM
> To: 'Mark J. Cerar'; 'Omega-list@xxxxxxxxxx'
> Subject: RE: EXE Code Too Large
>
>
> None of these products will impact the speed of a system to a great
> degree and it will all depend on how the systems are coded.
>
> We constantlyl use HASHUMS storing and retrieving 100's of variables
> from Systems running on the maximum amount of data that
> Tradestation can handle.. Therere is not a great speed loss.
>
> The TradeLab solution will not provide a significant
> advantage over the HASHNUMS and GLOBAL VARIABLES PRO.
> Indeed it may be much slower and more expensive. HASHNUMS
> interfaces to Visual C++, Visual Basic, Excel etc and allows data
> to be passed between the 2. HASHNUMS provides many more
> features in a Global variable product than Tradelabs Global Variables
> thing..
>
>
>
>
>
>
>
> -----Original Message-----
> From:	Mark J. Cerar [SMTP:mcerar@xxxxxxxxx]
> Sent:	Thursday, 17 September 1998 7:11
> To:	Jim McConnon; Omega List
> Subject:	RE: EXE Code Too Large
>
> Welcome to every TS programmers nightmare.  I have used the
> HashNums program
> but be warned passing values back and forth between TS and HashNums slows
> things down considerably especially in long RT charts.  You still
> might find
> it practical if you plan to pass values back and forth once or twice i.e.
> with one IncludeSystem Statement but after that Good Luck.  There might be
> an interesting solution at Scientific Approaches Tradelab.  Their Global
> Variables program interfaces with Visual Basic.  So you could pass the raw
> data to their Global Variables program, a Visual Basic program
> could process
> the data and pass it back to the Global Variables from where the TS system
> could import the results.  My thoughts are that this could be reasonably
> fast.  I have not used the SciApps TradeLab Modules but I'm
> looking hard at
> it right now.  There WebSite is http://sciapp.com/index.html
>
> Can anybody out their add their two cents worth?
>
> > -----Original Message-----
> > From: Jim McConnon [mailto:Jmcconno@xxxxxxxxxxxxx]
> > Sent: Wednesday, September 16, 1998 12:14 AM
> > To: Omega List
> > Subject: EXE Code Too Large
> >
> >
> > I have run up against the size limitation for systems in TS 4 build 21
> > (64k?).
> >
> > I have tried to slim down the code as much as possible.  I put
> some print
> > functions into an Include System.  I put some calculations into a
> > function,
> > but that seems like it uses up just as much space.
> >
> > Any thoughts? Use a DLL like Hashnums to pass values? I'm sure
> > others run up
> > against this and TS 5 is not here.
> >
> > Jim
> >
>