memory_profiler VS requests-html

memory_profiler

pythonprofilers/memory_profiler: Monitor Memory usage of Python code

# https://github.com/pythonprofilers/memory_profiler pip install memory_profiler psutil # psutil is needed for better memory_profiler performance python -m memory_profiler some-code.py Filename: some-code.py Line # Mem usage Increment Occurrences Line Contents ============================================================ 15 39.113 MiB 39.113 MiB 1 @profile 16 def memory_intensive(): 17 46.539 MiB 7.426 MiB 1 small_list = [None] * 1000000 18 122.852 MiB 76.312 MiB 1 big_list = [None] * 10000000 19 46.766 MiB -76.086 MiB 1 del big_list 20 46.766 MiB 0.000 MiB 1 return small_list

What do you do when your Python program is using too much memory? How do you find the spots in your code with memory allocation, especially in large chunks? It turns out that there is not usually an easy answer to these question, but a number of tools exist that can help you figure out where your code is allocating memory. In this article, I’m going to focus on one of them, memory_profiler.

requests-html

Ya, thanks for advice. When using requests_html library, I am trying to lower down the speed using response.html.render(timeout=1000), but it raise Runtime error instead on Google Colab: https://github.com/psf/requests-html/issues/517.

For dynamic js, prefer requests-html with xpath selection.

Example: requests-html which has a rather exhaustive README.md, but their dedicated page is not that helpful, if I remember correctly, and currently the domain is suspended.

When it comes to web scraping, the usual people recommend is beautifulsoup, lxml, or selenium. But I highly recommend people check out requests-html also. Its a library that is a happy medium between ease of use as in beautifulsoup and also good enough to be used for dynamic, javascript data where it would be overkill to use a browser emulator like selenium.

Quite possible. If you look at requests-html source code, it is simply one single python file that acts as a wrapper around a bunch of other packages, like requests, chromium, parse, lxml, etc., plus a couple convenience functions. So it could easily be some sort of bad dependency resolution.

What I do is try to see if I can use requests_html first before trying selenium. requests_html is usually enough if I dont need to interact with browser widgets or if the authentication isnt too difficult to reverse engineer.