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 >> >> -- >> Dan T. Abell :: dabell at txcorp dot com :: 303.444.2452 >> Tech-X Corp., 5621 Arapahoe Ave, Ste A, Boulder CO 80303 >> http://www.txcorp.com :: 303.748.6894/c 303.448.7756/fx >> >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >---------------------------------------------------------------------- >For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
