1. 27 Haz, 2001 9 kayıt (commit)
    • Martin v. Löwis's avatar
    • Fredrik Lundh's avatar
    • Fred Drake's avatar
      Revise the interface to the profiling and tracing support for the · 5755ce69
      Fred Drake yazdı
      Python interpreter.
      
      This change adds two new C-level APIs:  PyEval_SetProfile() and
      PyEval_SetTrace().  These can be used to install profile and trace
      functions implemented in C, which can operate at much higher speeds
      than Python-based functions.  The overhead for calling a C-based
      profile function is a very small fraction of a percent of the overhead
      involved in calling a Python-based function.
      
      The machinery required to call a Python-based profile or trace
      function been moved to sysmodule.c, where sys.setprofile() and
      sys.setprofile() simply become users of the new interface.
      
      As a side effect, SF bug #436058 is fixed; there is no longer a
      _PyTrace_Init() function to declare.
      5755ce69
    • Fred Drake's avatar
      Revise the interface to the profiling and tracing support for the · 55fb6e03
      Fred Drake yazdı
      Python interpreter.
      
      This change adds two new C-level APIs:  PyEval_SetProfile() and
      PyEval_SetTrace().  These can be used to install profile and trace
      functions implemented in C, which can operate at much higher speeds
      than Python-based functions.  The overhead for calling a C-based
      profile function is a very small fraction of a percent of the overhead
      involved in calling a Python-based function.
      
      The machinery required to call a Python-based profile or trace
      function been moved to sysmodule.c, where sys.setprofile() and
      sys.setprofile() simply become users of the new interface.
      55fb6e03
    • Fredrik Lundh's avatar
    • Barry Warsaw's avatar
      3f8c2e16
    • Thomas Wouters's avatar
    • Tim Peters's avatar
      This no longer leaks memory when run in an infinite loop. However, · f6ed0740
      Tim Peters yazdı
      that required explicitly calling LazyList.clear() in the two tests that
      use LazyList (I added a LazyList Fibonacci generator too).
      
      A real bitch:  the extremely inefficient first version of the 2-3-5 test
      *looked* like a slow leak on Win98SE, but it wasn't "really":  it generated
      so many results that the heap grew over 4Mb (tons of frames!  the number
      of frames grows exponentially in that test).  Then Win98SE malloc() starts
      fragmenting address space allocating more and more heaps, and the visible
      memory use grew very slowly while the disk was thrashing like mad.
      Printing fewer results (i.e., keeping the heap burden under 4Mb) made
      that illusion vanish.
      
      Looks like there's no hope for plugging the LazyList leaks automatically
      short of adding frameobjects and genobjects to gc.  OTOH, they're very
      easy to break by hand, and they're the only *kind* of plausibly realistic
      leaks I've been able to provoke.
      
      Dilemma.
      f6ed0740
    • Martin v. Löwis's avatar
      Encode surrogates in UTF-8 even for a wide Py_UNICODE. · ce9b5a55
      Martin v. Löwis yazdı
      Implement sys.maxunicode.
      Explicitly wrap around upper/lower computations for wide Py_UNICODE.
      When decoding large characters with UTF-8, represent expected test
      results using the \U notation.
      ce9b5a55
  2. 26 Haz, 2001 24 kayıt (commit)
  3. 25 Haz, 2001 7 kayıt (commit)