home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / lang / perl / 8012 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  3.3 KB
  1. Path: sparky!uunet!ferkel.ucsb.edu!taco!gatech!swrinde!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!ames!agate!doc.ic.ac.uk!pipex!demon!cix.compulink.co.uk!tbunce
  2. Newsgroups: comp.lang.perl
  3. From: tbunce@cix.compulink.co.uk (Tim Bunce)
  4. Subject: Memory allocation during @ary = <>;
  5. Reply-To: tbunce@cix.compulink.co.uk
  6. Date: Tue, 26 Jan 1993 21:59:00 +0000
  7. Message-ID: <memo.897439@cix.compulink.co.uk>
  8. Sender: usenet@demon.co.uk
  9. Lines: 65
  10.  
  11.  
  12. While tinkering with a large script to improve it's performance
  13. I started using trace(1) in the sun to watch the system calls.
  14.  
  15. The perl code reads in a large (>100k) text file, manipulates it,
  16. then writes it all back out again. Using trace -c to count the system
  17. calls I found:
  18.  
  19.      275 brk
  20.      180 read
  21.      161 write
  22.      etc
  23.  
  24. The reads and writes are ok (perl does it's i/o in 4096 bytes blocks)
  25. but 275 calls to brk (re malloc for those not familiar) seemed a little
  26. excessive.
  27.  
  28. The following is an extract from the trace output (data shown as dots):
  29. 21:08:16 read (3, "..................................".., 4096) = 4096
  30. 21:08:16 read (3, "..................................".., 4096) = 4096
  31. 21:08:16 read (3, "..................................".., 4096) = 4096
  32. 21:08:16 read (3, "..................................".., 4096) = 4096
  33. 21:08:16 read (3, "..................................".., 4096) = 4096
  34. 21:08:16 read (3, "..................................".., 4096) = 4096
  35. 21:08:16 read (3, "..................................".., 4096) = 4096
  36. 21:08:16 read (3, "..................................".., 4096) = 4096
  37. 21:08:16 read (3, "..................................".., 4096) = 4096
  38. 21:08:16 read (3, "..................................".., 4096) = 4096
  39. 21:08:16 read (3, "..................................".., 4096) = 4096
  40. 21:08:16 read (3, "..................................".., 4096) = 4096
  41. 21:08:16 read (3, "..................................".., 4096) = 4096
  42. 21:08:16 brk (0x276bb0) = 0
  43. 21:08:16 brk (0x279bb0) = 0
  44. 21:08:16 read (3, "..................................".., 4096) = 4096
  45. 21:08:16 brk (0x27cbb0) = 0
  46. 21:08:16 read (3, "..................................".., 4096) = 4096
  47. 21:08:16 brk (0x27fbb0) = 0
  48. 21:08:16 brk (0x282bb0) = 0
  49. 21:08:16 read (3, "..................................".., 4096) = 4096
  50. 21:08:16 brk (0x285bb0) = 0
  51. 21:08:16 brk (0x288bb0) = 0
  52. 21:08:16 read (3, "..................................".., 4096) = 4096
  53. 21:08:16 read (3, "..................................".., 4096) = 4096
  54. 21:08:16 brk (0x28bbb0) = 0
  55. 21:08:16 brk (0x28fbb0) = 0
  56. 21:08:16 read (3, "..................................".., 4096) = 4096
  57. 21:08:16 brk (0x293bb0) = 0
  58. etc etc
  59.  
  60. Notice that after a while perl is calling brk() for almost every read, Ouch!
  61. I presume here that perl is calling malloc() and malloc() is calling brk()
  62. because it has no spare memory.
  63.  
  64. I had hoped to improve performance by allocating lots of memory for a
  65. temporary variable and then freeing that memory before the read. This
  66. did not seem to affect the brk()'s, I presume the memory was not really
  67. free()'d. (I've tried many ways to allocate and free the memory.)
  68.  
  69. Is there a better solution? Is there a way to change the read ahead size
  70. from 4096? Given a virtual memory i/o system such as SunOS >4.1, a means
  71. of setting a larger read size should be very beneficial. Perl 5 perhaps :-)
  72.  
  73. Regards,
  74. Tim Bunce.
  75. tbunce@cix.compulink.co.uk
  76.