ray@spca6.UUCP (ray) (01/20/89)
In article <1996@lznh.UUCP> ariel@lznh.UUCP (<10000>Ariel Aloni) writes: >In article <300@spca6.UUCP> ray@spca6.UUCP (ray) writes: >>Just something every Unify HLI user should know, any call to unisort >>will cause a fork() system call. This is implicit in the manual, but >This is the first time i here this (shame :-). Umm, I guess it isn't general knowlede after all..... >Can you clarify on the issue ? First, I should stipulate that I can only report on what I have found on 3 version of Unify. They were 3.2 for the 3b1, 3.2 for an Arete 1200, and 4.0 for an Arete 1200. >Is an exec* also involved ? (probably yes, and an exec is much more >exepensive than a fork on most Unix sytems). In all three of these environments, the unisort() call will cause a fork and then an exec of sort(1). >The only thing that caught my eye in the manual is something about >a "general sorting function ...". Do they mean sort(1) ? That's the implicit reference I am refering to... and in the environments I've run Unify in they do mean sort(1) I glossed over that reference too. Until one day another programmer in the shop was writing a program. That program seemed to be taking longer to run than it should. So I told him to profile it. Since he had never ran the profiler, I had to help him. I was shocked to see that 33% of his program's time was spent executing a fork() call. He did not code a fork call in his program. Finally, we observed that unisort() was called the same number of times as fork(). Well needless to say, we did some digging into the librarys and found out that in fact unisort()==(fork(); exec("sort", "sort","infile","-o","outfile")); :-( When he rewrote his program to remove the unisorts,it ran in 2 minutes time instead of 12 minutes! And the moral of the story is..... If you care about efficiency at all, run your code through the profiler. === ray mit-eddie!uccba!spca6!ray