Thanks for this! > ... > Then a simple script that maps the file, looks at the area of the > phone calls and aggregates the time for the calls, sums the cost and > gets the average cost/minute for the aggregated areas - run under the > same time command. > ...
Readers of the forum should know that some of the special code in http://www.jsoftware.com/help/dictionary/special.htm are "JKT specials", for which we also have to thank Joey. ----- Original Message ----- From: Joey K Tuttle <[email protected]> Date: Sunday, August 28, 2011 0:06 Subject: Re: [Jgeneral] Timing J startup To: General forum <[email protected]> Cc: General forum <[email protected]> > I use j all the time in cgi scripts, people accessing > information > from a browser don't notice any hesitation in response. If the > calling frequency is high, then you could leave a j task running > and > communicate with it through sockets - I have put things like > that > together in the past. > > A direct answer to your question is that the load time is very > small. > Here is a "Hello World" progam in j in a 64 bit Unix environment > (in > my case OSX) - > > iMi7:pfc jkt$ cat hw > #! /usr/local/bin/j64 -jprofile > 'Hello World' 1!:2 ] 4 > 2!:55] 0 > > iMi7:pfc jkt$ time ./hw > Hello World > real 0m0.004s > user 0m0.001s > sys 0m0.002s > iMi7:pfc jkt$ > > "time" is a Unix command that gives the real, user, and system > time > to complete a command line request - in this case, executing the > j > "Hello World" script. As you can see, the time is quite > short indeed. > > I also have lots of scripts that do utility tasks, one I > demonstrated > in the course of presenting a talk at the last J conference > (shame > there haven't been any more of them...) > > The first time I addressed these things was at the 1996 j user > meeting and a background note can be found at - > > http://www.jsoftware.com/papers/tuttle.htm > > The demonstration I made in the j2000 conference involved > analyzing a > phone bill. The size of the data file for the bill is fairly > large, > here is a Unix command that counts the lines, words and bytes of > the > file - > > iMi7:mci jkt$ time wc 113997.001 > 564218 11747126 227944072 113997.001 > > real 0m1.378s > user 0m1.304s > sys 0m0.073s > > The file name is 113997.001 and is a file with 564,218 lines, > each > 404 characters long for a total file size of 227,944,072 bytes. > I did > it a few times so that the file was cached and reading the 225 > megabytes is primarily from the cache - so no disk delays. > > Then a simple script that maps the file, looks at the area of > the > phone calls and aggregates the time for the calls, sums the cost > and > gets the average cost/minute for the aggregated areas - run > under the > same time command. This script loads j, has j read in a script > with > the verbs to do the analysis, maps the file to a 564218 by 404 > table > and then does the computations - here are the results and times > for > all that > > iMi7:mci jkt$ time ./mcisummary 113997.001 > Mapped name of 113997.001 is cdf > 08 INA > 1 0.2 0.01 3.05 > 08 INE > 97 75.5 2.39 3.16 > 09 ALA > 3613 2881.0 > 265.05 9.20 > 09 CAN 8715 > 10836.1 775.84 7.16 > 09 CAR > 126 111.6 > 30.08 26.95 > 09 EDL > 19 25.4 3.61 14.22 > 09 HAW > 1107 1462.6 > 114.62 7.84 > 09 INA 20959 > 20996.7 625.97 2.98 > 09 INE 527143 539187.3 > 16501.82 3.06 > 09 INT > 1777 2103.0 > 463.28 22.03 > 09 MEX > 139 142.9 > 27.15 19.00 > 09 PUE > 472 650.6 > 58.60 9.01 > 09 VIR > 50 51.5 4.64 9.01 > > real 0m0.515s > user 0m0.375s > sys 0m0.136s > iMi7:mci jkt$ > > If anyone is curious, the columns in the "report" are - > Product Code, Area, Number of calls. Aggregated time, Aggregated > cost, and average cost/minute. > > So, you can see that the real time (including the delays in > loading > j, setting up the mapping and doing all the work is about half a > second and that is less than half of the time that the Unix > command > wc requires just to count the lines, words, and bytes of the file. > > To be fair, if wc only counts lines and bytes, it is a bit faster: > > iMi7:mci jkt$ time wc -lc 113997.001 > 564218 227944072 113997.001 > > real 0m0.292s > user 0m0.216s > sys 0m0.076s > iMi7:mci jkt$ > > But even then it isn't much faster than doing a good deal of > analysis > in the j script. The setup/load time is a very minor part of > this. > Another example was a j script I put together for some challenge > about taking a text and counting the words in it and reporting > the 10 > most frequently used words and how many times they appeared. > Here is > one version of that script: > > iMi7:pfc jkt$ cat p64 > #! /usr/local/bin/j64 -jprofile > lmap =: (32 ,~ 32 39 95, (48 +i.10),, 97 97 > +/i.26){a. umap =: (32 39 95, (48 +i.10),, 65 > 97 +/i.26){a. > syms =: s:' ',(umap i.1!:1]3{ARGV){lmap > words =: (#~ (~:~ {.)) syms > cnts =: #/.~ words > p =: ({:0". '10 ',;4}.ARGV) {. \: cnts =: > #/.~ words > 1!:2&4 , (10{a.),.~ (": ,.(#words), > p{cnts),.' ',. ' ', >5&s: p{~.words > 2!:55] 0 > > The text I used for testing was the Jane Austen novel "Emma" - > > iMi7:pfc jkt$ time ./p64 Emma > 161092 > 5242 to > 5204 the > 4897 and > 4293 of > 3191 i > 3130 a > 2529 it > 2483 her > 2400 was > 2364 she > > real 0m0.036s > user 0m0.024s > sys 0m0.009s > iMi7:pfc jkt$ > > the results (in 36 milliseconds total elapsed time) shows the > count > of words (161,092) and the ordered usage count of the top 10. So > this > is another indication that the load/setup time for j is very low. > > I think j does very well as a dynamic environment for analysis. > > - joey > > At 21:58 -0400 2011/08/27, Tracy Harms wrote: > >The man I'm thinking of was wishing he had a dynamic language > with support > >for a variety of numeric types and a loading time of not more > than 0.3 > >seconds. He gets good response times from luajit and > javascript's v8 but > >with those he does not get integers. > > > >He apparently needs to fire off a script through automation and > produces a > >result quickly, but not through an interactive session. Any > degree of > >responsiveness might be required with such uses. The > applications commonly > >solved in K involve very small portions of a second, for instance. > > > >I know nothing about his problem domain beyond what I've said > here. I was > >just casually curious how close J might be to competitive in > fitting his > >needs, given this narrow set of criteria. > > > >--Tracy > > On Aug 27, 2011 5:49 PM, "Dan T. Abell" > <[email protected]> wrote: > >> 'Tis a sad day when people would complain about an app > >> that takes maybe a few seconds to load. > >> > >> Mathematica is a true memory hog and takes its own > >> sweet time loading. The most time-consuming part of > >> firing up J is clicking "Exit to J Session". (Yes, > >> I could check the "Don't show this again", but I still > >> count my self a newbie.) > >> > >> J is a thinking man's (or woman's) app, and the thinking > >> is for sure the part that takes me the longest to load. > >> > >> My $0.02, > >> -Dan > >> > >> On 27 Aug 2011, at 13:07, Tracy Harms wrote: > >> > >>> I'd like to tell somebody how fast J loads on my > machine, but not sure > >how > >>> to time it. I know how to time things within J once it > is up, but not how > >>> long it takes to come up. > >>> > >>> I happen to be using Windows 7, 64 bit, and most > interested in timing > >J602, > >>> but if it's worth discussing answers here it makes > sense to consider all > >the > >>> combinations > >>> > >>> --Tracy ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
