Pith. sign in

REVIEW 4 major objections 3 minor 47 references

PandasBench: A Benchmark for the Pandas API

T0 review · 4 major / 3 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper introduces PandasBench, the first Pandas API benchmark built from 102 real Kaggle notebooks, and shows that on it most Pandas optimization techniques slow code down rather than speed it up.

desk verdict PandasBench is the first credible large real-world Pandas benchmark and its coverage results are important, but the unvalidated manual cleaning pipeline and a notebook-count inconsistency undermine the representativeness claim until audited. read the letter →

arxiv 2506.02345 v2 pith:T7X4FO4I submitted 2025-06-03 cs.DB cs.SE

Alex Broihier , Stefanos Baziotis , Daniel Kang , Charith Mendis This is my paper · ORCID
classification cs.DBcs.SE
keywords PandasAPIbenchmarkreal-worldcoveragenotebookworkloadsdatascalingModinDaskKoalas
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that no usable benchmark exists for the Pandas API, and that existing benchmarks from SQL or array computing cannot be borrowed. To fix that, it introduces PandasBench: 102 randomly selected, executable Kaggle notebooks (3,721 cells) that were manually fixed, cleaned of non-Pandas code, adapted for repeated runs, and given per-notebook non-uniform input scaling. The paper uses PandasBench to evaluate four Pandas optimization techniques. It reports that Modin speeds up only 8 of 102 notebooks (~8%), Dask and Koalas speed up none, and Dias speeds up about half while also rewriting some code incorrectly. If these results hold, the speedups reported in earlier constrained evaluations do not transfer to whole real-world Pandas workloads.

What carries the argument

The load-bearing object is the benchmark construction pipeline: random download of 102 Kaggle notebooks with at least 10 cells and at least 20% Pandas API calls; a manual stage that fixes library-version and input-code mismatches, cleans out machine-learning and plotting code while preserving dependent Pandas code, adapts notebooks for repeated execution and eager evaluation of lazy results; and a scaling stage that duplicates or removes rows per notebook to hit a target runtime instead of applying one uniform factor to all data. The paper's definition of real-world coverage (RWC1-RWC3) and the four requirements RWC, REL, APPR, and DSC are the criteria that distinguish PandasBench from prior collections.

What would settle it

Take the released notebooks with their original Kaggle inputs, run them as downloaded, and compare the set of Pandas API calls, column types, and row counts against the cleaned versions; any material difference in what executes would show PandasBench is not measuring the original real-world code.

Watch

Extended reading notes

Core claim

The paper's central claim is that real-world coverage — code that is real, executable, large, and diverse — is the necessary standard for any Pandas API benchmark, and that PandasBench is the first collection satisfying all four requirements it defines: real-world coverage, relevant code only, benchmark-appropriate execution, and effective data scaling. On this benchmark, the paper finds that popular Pandas alternatives largely fail or slow down: Modin runs 72/102 notebooks (~70%) and speeds up 8/102 (~8%) at best; Dask runs 4 notebooks and speeds up none; Koalas runs 10 and speeds up none; Dias runs 97 but produces incorrect rewrites in cases prior work missed. The paper also finds that scaling matters: some notebooks fail only after upscaling (Koalas out-of-memory, Modin internal errors), and one Dask notebook succeeds only after downscaling because a problematic float is cut away. This is presented as evidence that prior speedups came from constrained, often synthetic or tiny test sets.

Load-bearing premise

The load-bearing premise is that the manual fixing, cleaning, adapting, and rescaling in Section 4.5 did not change which computations the notebooks perform or how they behave; if those edits did, the benchmark would be measuring edited code rather than real-world Pandas code.

Editorial extensions

If this is right

  • Prior favorable evaluations of Modin, Dask, and Koalas on small or synthetic Pandas code do not predict whole-notebook behavior: on PandasBench, 92% or more of real notebooks are not sped up.
  • A Pandas alternative cannot act as a drop-in replacement if it fails to run 30% (Modin) to 96% (Dask) of real notebooks.
  • Benchmark scaling is not neutral: coverage and relative performance shift with input size, so a useful Pandas benchmark must support per-notebook, non-uniform scaling and report results across target runtimes.
  • Techniques that rewrite Pandas code (Dias) need correctness checks on real workloads, since PandasBench found incorrect rewrites that earlier, smaller evaluations did not expose.
  • PandasBench provides a reusable 102-notebook suite with data and harness so future Pandas API techniques can report coverage, speedup, and memory/disk usage on real-world code.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Beyond the paper: because the benchmark scales each notebook to a target runtime, the published speedups may understate how these techniques behave on the original, often much smaller Kaggle inputs, where startup overheads make up a larger share of runtime.
  • Beyond the paper: the failure taxonomy (missing method, missing argument, unsupported use case, invalid output, bad type inference, scaling error) could be turned into a compatibility regression suite for Pandas API implementations.
  • Beyond the paper: the finding that about 10% of input files stress type inference, plus a notebook producing a transposed frame with millions of columns, suggests targeted microbenchmarks for inference engines and transpose-heavy workloads would complement PandasBench.
  • Beyond the paper: a direct test of reusability would be whether two independent teams following the same manual preparation rules converge on similar notebooks and close to the same coverage counts.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 3 minor

Summary. PandasBench is presented as a benchmark suite of 102 real-world Kaggle notebooks (3,721 cells) for the Pandas API. The paper proposes four requirements for such a benchmark—real-world coverage, relevance of code, benchmark appropriateness, and data scaling—and argues that no existing collection satisfies them. The authors describe a manual pipeline that fixes broken code, cleans out non-Pandas code, adapts notebooks for repeated execution, and scales input data non-uniformly. They use the benchmark to evaluate Modin, Dask, Koalas, and Dias, reporting low real-world coverage for the alternatives (Modin 72/102, Dask 3–4, Koalas 10) and mostly slowdowns relative to pandas, with Dias the only technique achieving speedups on a substantial subset (up to 55 notebooks). The headline conclusion is that prior constrained benchmarks overstate the speedups of Pandas alternatives.

Significance. If correct, PandasBench would be the first large, executable, real-world benchmark for the Pandas API, and the negative results for Modin, Dask, and Koalas would be an important correction to prior evaluations based on small or synthetic workloads. The paper's strengths include a publicly available artifact, a detailed description of the preparation pipeline, dynamic API coverage analysis, a non-uniform scaling infrastructure, and the largest head-to-head evaluation of these techniques to date. These are substantial empirical contributions. The main limitation is that the manual preparation pipeline's fidelity to the original notebooks is asserted but not validated; this currently weakens the benchmark's representativeness claim and, in turn, the strength of the negative results.

major comments (4)
  1. [§3 and §4] The sampling and retention narrative is internally inconsistent. §3 states that 102 notebooks were downloaded randomly, while §4 states that 'we fixed and cleaned 114 notebooks and discarded 12 notebooks after applying the process in §4.5.' These numbers do not reconcile: if 102 is the final count, the pre-discard count would have to be 114, meaning 12 additional notebooks are unaccounted for in §3; alternatively, if 102 is the download count, fixing and cleaning 114 is impossible. The criteria for discarding the 12 notebooks are also never specified. Since the paper's central claim is a random sample of real-world notebooks, the reader must be able to trace the exact path from initial download to final benchmark; without this, the randomness and representativeness claims are unverifiable.
  2. [§4.5 and Appendix B] The manual preparation pipeline is the load-bearing premise for the claim that PandasBench evaluates real-world Pandas code, but the paper provides no validation that the edited notebooks preserve the semantics and performance-relevant behavior of the originals. The pipeline explicitly deletes code that depends on non-Pandas libraries 'even if it includes Pandas code', removes following uses of columns whose assignments were deleted, replaces hardcoded values with runtime values, inserts evaluate_eager calls for lazy evaluation, and scales inputs. Each of these steps can change which Pandas operations execute, how they execute, or what data they observe. The paper reports no differential testing between original and prepared notebooks, no edit-size statistics (e.g., the fraction of cells or API calls removed or altered per notebook), and no independent audit of the manual fixes. I am not accusing the edits of being incorrect; rather, this is a missing validation step for a benchmark whose entire purpose is representativeness. The authors should provide evidence such as before/after API-call coverage comparisons on a sample, a per-notebook log of edits, or an external audit of the preparation process.
  3. [Abstract and §6.2] The abstract reports that Dask ran 4 notebooks (~4%), while §6.2 states that Dask 'could run only 3 (~3%)' and Figure 3a shows 3. One of these is incorrect. This inconsistency affects one of the paper's headline claims—that the most notebooks that got a speedup were 8/102 for Modin and 0 for both Koalas and Dask—because the Dask coverage count is part of that comparative statement. Please correct the discrepancy and audit all other reported counts (including cell-level coverage figures) for consistency.
  4. [§1 contribution bullet and §3] The contribution bullet describes the benchmark as composed of 'real-world, randomly picked notebooks.' This overstates the sampling procedure: §3 applies explicit filters—at least 20% of static calls from the Pandas API, at least 10 cells, and exclusion of all 20 Dias notebooks—and the paper later discards 12 more notebooks during preparation. The sample is therefore a filtered random sample of Kaggle notebooks satisfying stated criteria, not a random sample of Kaggle notebooks generally. Without this qualification, the diversity claim (RWC3) is difficult to evaluate, and the reader may mistakenly conclude the benchmark represents all Kaggle notebooks. The wording should be changed to describe the actual selection procedure.
minor comments (3)
  1. [Abstract] The abstract contains a typo: 'Pandas API enchmark' should be 'Pandas API benchmark.'
  2. [§6.1.5] The final paragraph states 'This process was done automatically although in principle it could be automated.' This is self-contradictory; presumably the intended wording is that the process was done manually although in principle it could be automated. Please fix.
  3. [§6.3.1] The formula for the geometric mean memory+disk ratio is typeset incorrectly: the expression 'GeoMean {...}' with the fraction 'I_T,R / I_pandas,R' is garbled and lacks proper subscripts and delimiters. It should be written as the geometric mean over notebooks in N_{T,R} of I_{T,R}(i) / I_{pandas,R}(i). Please correct the equation.

Circularity Check

0 steps flagged · score 1.0 of 10

No significant circularity; benchmark measurements are empirical and not derived from the benchmark's own definitions.

full rationale

PandasBench's central claims are construction and evaluation claims, not derivations. The four requirements (RWC, REL, APPR, DSC) are normative definitions; saying the benchmark fulfills them is a design property, not a prediction derived from the definitions. Coverage and speedup are measured by executing Modin, Dask, Koalas, and Dias on the prepared notebooks and comparing runtimes to a pandas baseline (Section 6), so no fitted parameter is renamed as a prediction and no equation reduces to another by construction. The only self-involvement is that two co-authors are also authors of Dias, the technique that performs best; the paper explicitly excludes Dias's 20 notebooks (Section 3) and reports negative results about Dias (incorrect rewrites, Section 6.2.1), which makes this a conflict-of-interest caution rather than a logical circularity. The unvalidated manual preparation pipeline (Section 4.5, 'we applied the process manually since ... we could not devise an algorithm that achieves all the goals') is a genuine validity risk because edits may change semantics or performance-relevant behavior, and the count of 102 vs. 114 notebooks is confusing; however, that is a missing-validation/correctness concern, not a circularity, because the paper does not use the preparation rules as evidence for its empirical conclusions.

Assumptions & free parameters 6 free parameters · 4 assumptions · 0 invented entities

The benchmark rests on experimental choices rather than derivation. The main free parameters are inclusion thresholds, target runtimes, the scaling upper bound, CPU count, and tool versions, all chosen by hand and all capable of moving the reported numbers. The axioms are domain assumptions about Kaggle representativeness, the faithfulness of manual edits, single-machine scope, and the pandas 1.5.1 baseline. No invented entities are introduced.

free parameters (6)
  • Pandas heavy-use inclusion threshold = 20% of static calls from Pandas API
    Chosen by hand in §3 to define 'heavy use'; a different threshold changes which notebooks enter the benchmark and therefore the coverage results.
  • Minimum notebook length = 10 cells
    Chosen by hand in §3; filters out short notebooks and affects diversity and coverage.
  • Target runtimes for scaling = 5, 10, 20 seconds, plus default unscaled
    Scale factors are iteratively tuned to hit these runtimes (§6.1.5); speedup and coverage are measured at these chosen points rather than at fixed data sizes.
  • Scaling upper-bound factor = 1.33x target runtime
    Upper bound introduced in §6.1.5 to cap notebook runtime; arbitrary and influences downscaling decisions.
  • CPU core count for alternatives = 4 cores
    Set in §6.1.4 to mimic Kaggle and Colab; parallel engines' speedups depend strongly on this choice.
  • Technique versions = Modin 0.17.0, Dask 2024.4.1, Koalas 3.5.1, Dias 0.1.2
    Fixed versions in §6.1.3; coverage and correctness issues may be version-specific.
assumptions (4)
  • domain assumption Kaggle notebooks satisfying the stated filters are representative of real-world Pandas API code
    Used to satisfy RWC1 and RWC3; no external validation that Kaggle usage covers all Pandas workloads.
  • domain assumption Manual fixing, cleaning, and adaptation preserves the semantics and performance-relevant behavior of the original notebooks
    The entire benchmark construction in §4.5 is manual; if edits change behavior, the real-world coverage claim is weakened.
  • domain assumption Single-machine workloads are the appropriate scope for a Pandas API benchmark
    The paper deliberately excludes distributed and multi-machine usage, limiting generality but matching many Kaggle and Colab workloads.
  • domain assumption pandas 1.5.1 is a fair baseline for current Pandas alternatives
    Speedups are computed relative to this specific version; pandas 2.x with Arrow is not tested and may change the numbers.

how reviews work

0 comments
Cite this review

Pith. "Pith review of PandasBench: A Benchmark for the Pandas API." pith.science (2026). https://pith.science/paper/T7X4FO4I

@misc{pith2026250602345,
  author       = {Pith},
  title        = {Pith review of: PandasBench: A Benchmark for the Pandas API},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/T7X4FO4I}},
  note         = {Machine review of arXiv:2506.02345}
}
read the original abstract

The Pandas API has been central to the success of pandas and its alternatives. Despite its importance, there is no benchmark for it, and we argue that we cannot repurpose existing benchmarks (from other domains) for the Pandas API. In this paper, we introduce requirements that are necessary for a Pandas API enchmark, and present the first benchmark that fulfills them: PandasBench. We argue that it should evaluate the real-world coverage of a technique. Yet, real-world coverage is not sufficient for a useful benchmark, and so we also: cleaned it from irrelevant code, adapted it for benchmark usage, and introduced input scaling. We claim that uniform scaling used in other benchmarks (e.g., TPC-H) is too coarse-grained for PandasBench, and use a non-uniform scaling scheme. PandasBench is the largest Pandas API benchmark to date, with 102 notebooks and 3,721 cells. We used PandasBench to evaluate Modin, Dask, Koalas, and Dias. This is the largest-scale evaluation of all these techniques to date. Prior works report significant speedups using constrained benchmarks, but we show that on a larger benchmark with real-world code, the most notebooks that got a speedup were 8/102 (~8%) for Modin, and 0 for both Koalas and Dask. Dias showed speedups in up to 55 notebooks (~54%), but it rewrites code incorrectly in certain cases, which had not been observed in prior work. Second, we identified many failures: Modin runs only 72/102 (~70%) notebooks, Dask 4 (~4%), Koalas 10 (~10%), and Dias 97 (95%).

Figures

Figures reproduced from arXiv: 2506.02345 by the authors.

Figure 1
Figure 1. An overview of the construction of PandasBench. In the remainder of the paper, we describe how PandasBench was formed and we present one use case: evaluating different Pan￾das optimization techniques. In §3 we describe how we collected the notebooks. In §4 we describe how we prepared the notebooks to fix them, clean them, adapt them, and scale their data [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Histogram of column types of the datasets that are [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. Number of notebooks that each Pandas optimiza [PITH_FULL_IMAGE:figures/full_fig_p007_3.png] view at source ↗
Figures from the paper (5 more)
Figure 4
Figure 4. Figure 4: Per-notebook speedups of Modin compared to [PITH_FULL_IMAGE:figures/full_fig_p010_4.png]
Figure 5
Figure 5. Figure 5: Per-notebook speedups of Dask compared to [PITH_FULL_IMAGE:figures/full_fig_p010_5.png]
Figure 7
Figure 7. Figure 7: Per-notebook speedups of Dias compared to vanilla [PITH_FULL_IMAGE:figures/full_fig_p011_7.png]
Figure 8
Figure 8. Figure 8: Per-cell absolute speedups (excluding speedups near [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Maximum and geometric-mean relative mem￾ory+disk usage of Modin, Dask, and Koalas compared to pandas. Dias is excluded because its usage is near-constant. memory usage is lower than the pandas geometric-mean usage. Koalas especially excels with scalability, having a pe…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

47 extracted references · 37 canonical work pages

  1. [1]

    Ashfaque

    Johar M. Ashfaque. 2020. SARIMA Time series EDA & Predict - JMA Sao Paulo. https://www.kaggle.com/code/ukveteran/sarima-time-series-eda-predict- jma-sao-paulo

    work page 2020

  2. [2]

    Niels Bantilan. 2020. https://github.com/unionai-oss/pandera/pull/344

    work page 2020

  3. [3]

    Niels Bantilan. 2024. Pandera: Going Beyond Pandas Data Validation. In2023 Python in Science Conferences (SciPy). https://doi.org/10.25080/gerudo-f2bc6f59- 010

    work page doi:10.25080/gerudo-f2bc6f59- 2024

  4. [4]

    Stefanos Baziotis, Daniel Kang, and Charith Mendis. 2024. Dias: Dynamic Rewrit- ing of Pandas Code.Proc. ACM Manag. Data2, 1, Article 58 (March 2024), 27 pages. https://doi.org/10.1145/3639313

    doi:10.1145/3639313 2024

  5. [5]

    Polars — Updated TPC-H benchmark results. 2024. https://pola.rs/posts/ benchmarks/

    work page 2024

  6. [6]

    We Downloaded 10000000 Jupyter Notebooks From Github – This Is What We Learned | The Datalore Blog. 2020. https://blog.jetbrains.com/datalore/2020/12/ 17/we-downloaded-10-000-000-jupyter-notebooks-from-github-this-is-what- we-learned/

    work page 2020

  7. [7]

    CalmeToi. 2016. Classifying Client Type using Client Names. https://www. kaggle.com/code/poiss0nriot/classifying-client-type-using-client-names

    work page 2016

  8. [8]

    Brian Alberto Mendieta Camacho. 2023. Data Cleaning plus EDA. https://www. kaggle.com/code/brianmendieta/data-cleaning-plus-eda

    work page 2023

Show all 47 references
  1. [9]

    Google Colab Exploratory data analysis in Python. 2019. https: //colab.research.google.com/github/Tanu-N-Prabhu/Python/blob/master/ Exploratory_data_Analysis.ipynb

    2019

  2. [10]

    Dask DataFrame Dask documentation. 2018. https://docs.dask.org/en/stable/ dataframe.html

    2018

  3. [11]

    Dimitrios Effrosynidis. 2018. EDA is Fun! https://www.kaggle.com/code/deffro/ eda-is-fun

    2018

  4. [12]

    Apache Software Foundation. 2025. Apache Arrow. https://arrow.apache.org/. PandasBench: A Benchmark for the Pandas API

    2025

  5. [13]

    Serge Guelton. 2021. numpy-benchmarks. https://github.com/serge-sans-paille/ numpy-benchmarks

    2021

  6. [14]

    Serge Guelton. 2025. Pythran tests. https://github.com/serge-sans-paille/ pythran/tree/master/pythran/tests

    2025

  7. [15]

    Surabhi Gupta and Karthik Ramachandra. 2021. Procedural extensions of SQL: understanding their usage in the wild.Proc. VLDB Endow.14, 8 (April 2021), 1378–1391. https://doi.org/10.14778/3457390.3457402

    2021

  8. [16]

    guy almog. 2020. HR Analytics - Predicting Employees Attrition. https://www. kaggle.com/code/guyalmog/hr-analytics-predicting-employees-attrition

    2020

  9. [17]

    Kaggle Homepage. 2025. https://www.kaggle.com/

    2025

  10. [18]

    Anaconda Inc. 2025. airspeed velocity of an unladen numba. https://numba. pydata.org/numba-benchmark/

    2025

  11. [19]

    Jagan. 2018. Stop the S@#$ - Toxic Comments EDA. https://www.kaggle.com/ code/jagangupta/stop-the-s-toxic-comments-eda

    2018

  12. [20]

    Alekh Jindal, K Venkatesh Emani, Maureen Daum, Olga Poppe, Brandon Haynes, Anna Pavlenko, Ayushi Gupta, Karthik Ramachandra, Carlo Curino, Andreas Mueller, et al. 2021. Magpie: Python at Speed and Scale using Cloud Backends.. InCIDR

    2021

  13. [21]

    Matthew Rocklin. 2015. Dask: Parallel Computation with Blocked algorithms and Task Scheduling. InProceedings of the 14th Python in Science Conference, Kathryn Huff and James Bergstra (Eds.). 126 – 132. https://doi.org/10.25080/Majora- 7b98e3ed-013

    2015 doi

  14. [22]

    Jordan, and Ion Stoica

    Philipp Moritz, Robert Nishihara, Stephanie Wang, Alexey Tumanov, Richard Liaw, Eric Liang, Melih Elibol, Zongheng Yang, William Paul, Michael I. Jordan, and Ion Stoica. 2018. Ray: a distributed framework for emerging AI applica- tions. InProceedings of the 13th USENIX Confere...

    2018

  15. [23]

    Mojtaba Mostafavi Ghahfarokhi, Arash Asgari, Mohammad Abolnejadian, and Abbas Heydarnoori. 2024. DistilKaggle: A Distilled Dataset of Kaggle Jupyter Notebooks. InProceedings of the 21st International Conference on Mining Software Repositories(Lisbon, Portugal)(MSR ’24). Associ...

    2024

  16. [24]

    Shoumik Palkar, James Thomas, Deepak Narayanan, Pratiksha Thaker, Rahul Palamuttam, Parimajan Negi, Anil Shanbhag, Malte Schwarzkopf, Holger Pirk, Saman Amarasinghe, Samuel Madden, and Matei Zaharia. 2018. Evaluating end-to-end optimization for data analytics applications in w...

    2018

  17. [25]

    Koalas: pandas API on Apache Spark. 2023. https://koalas.readthedocs.io/en/ latest/

    2023

  18. [26]

    pepy.tech: Modin downloads. 2024. https://pepy.tech/projects/modin

    2024

  19. [27]

    Gonzalez, Joseph M

    Devin Petersohn, Stephen Macke, Doris Xin, William Ma, Doris Lee, Xiangxi Mo, Joseph E. Gonzalez, Joseph M. Hellerstein, Anthony D. Joseph, and Aditya Parameswaran. 2020. Towards scalable dataframe systems.Proc. VLDB Endow. 13, 12 (jul 2020), 2033–2046. https://doi.org/10.1477...

    2020

  20. [28]

    Gonzalez, Anthony D

    Devin Petersohn, Dixin Tang, Rehan Durrani, Areg Melik-Adamyan, Joseph E. Gonzalez, Anthony D. Joseph, and Aditya G. Parameswaran. 2021. Flexible rule- based decomposition and metadata independence in modin: a parallel dataframe system.Proc. VLDB Endow.15, 3 (Nov. 2021), 739–7...

    2021

  21. [29]

    Github: pola-rs/polars benchmark. 2024. https://github.com/pola-rs/polars- benchmark/tree/cf31c4dbc25300426666125c998b6010190427f2

    2024

  22. [30]

    Fotis Psallidas, Yiwen Zhu, Bojan Karlas, Jordan Henkel, Matteo Interlandi, Subru Krishnan, Brian Kroth, Venkatesh Emani, Wentao Wu, Ce Zhang, Markus Weimer, Avrilia Floratou, Carlo Curino, and Konstantinos Karanasos. 2022. Data Science Through the Looking Glass: Analysis of M...

    2022

  23. [32]

    Luigi Quaranta, Fabio Calefato, and Filippo Lanubile. 2021. KGTorrent: A Dataset of Python Jupyter Notebooks from Kaggle. In2021 IEEE/ACM 18th International Conference on Mining Software Repositories (MSR). IEEE. https://doi.org/10.1109/ msr52588.2021.00072

    2021

  24. [33]

    Nihhaar RC. 2019. ETLTransform. https://www.kaggle.com/code/nihhaar/ etltransform

    2019

  25. [35]

    Adam Rule, Aurélien Tabard, and James D. Hollan. 2018. Exploration and Ex- planation in Computational Notebooks. InProceedings of the 2018 CHI Con- ference on Human Factors in Computing Systems(Montreal QC, Canada)(CHI ’18). Association for Computing Machinery, New York, NY, U...

    2018

  26. [36]

    Python for Social Scientists San Diego State University, Linguistics/BDA 572

  27. [37]

    Ponder: The Efficient Data Scientist. 2022. https://www.intelcapital.com/ponder- the-efficient-data-scientist/

    2022

  28. [38]

    Charulata Shelar. 2020. Indian Startup Funding - Exploratory Data Anal- ysis. https://www.kaggle.com/code/charulatashelar/indian-startup-funding- exploratory-data-analysis

    2020

  29. [39]

    Sudarshan

    Bhushan Pal Singh, Mudra Sahu, and S. Sudarshan. 2021. Optimizing Data Science Applications using Static Analysis. InThe 18th International Sympo- sium on Database Programming Languages(Copenhagen, Denmark)(DBPL ’21). Association for Computing Machinery, New York, NY, USA, 23–...

    2021

  30. [40]

    sudheerchowdary. 2017. House Price Prediction. https://www.kaggle.com/code/ sudheer259/house-price-prediction

    2017

  31. [41]

    2022.TPC Benchmark TM H Stan- dard Specification(3.0.1 ed.)

    Transaction Processing Performance Council. 2022.TPC Benchmark TM H Stan- dard Specification(3.0.1 ed.). Transaction Processing Performance Council, San Francisco, CA, USA. https://www.tpc.org/TPC_Documents_Current_Versions/ pdf/TPC-H_v3.0.1.pdf

    2022

  32. [42]

    Transaction Processing Performance Council. 2024. TPC Benchmarks Overview. https://www.tpc.org/information/benchmarks5.asp

    2024

  33. [43]

    Ray v2 Architecture. 2022. https://docs.google.com/document/d/ 1tBw9A4j62ruI5omIJbMxly-la5w4q_TjyJgJL_jN2fI/preview

    2022

  34. [44]

    Waller and Stanley E

    Matthew A. Waller and Stanley E. Fawcett. 2013. Data Science, Predictive Analyt- ics, and Big Data: A Revolution That Will Transform Supply Chain Design and Management.Journal of Business Logistics34, 2 (2013), 77–84. https://doi.org/10. 1111/jbl.12010 arXiv:https://onlinelibr...

    2013 doi

  35. [45]

    Solving Real-World Business Questions with Python Pandas. 2020. https://medium.com/li-ting-liao-tiffany/solving-real-world-business- questions-with-pandas-70ef8ef02675

    2020

  36. [46]

    Franklin, Scott Shenker, and Ion Stoica

    Matei Zaharia, Mosharaf Chowdhury, Michael J. Franklin, Scott Shenker, and Ion Stoica. 2010. Spark: cluster computing with working sets. InProceedings of the 2nd USENIX Conference on Hot Topics in Cloud Computing(Boston, MA) (HotCloud’10). USENIX Association, USA, 10

    2010

  37. [47]

    Alexandros Nikolaos Ziogas, Tal Ben-Nun, Timo Schneider, and Torsten Hoefler

  38. [2021]

    those methods that perform relational operations or operations that are commonly supported by popular database systems,

    NPBench: a benchmarking suite for high-performance NumPy. InPro- ceedings of the 35th ACM International Conference on Supercomputing(Virtual Event, USA)(ICS ’21). Association for Computing Machinery, New York, NY, USA, 63–74. https://doi.org/10.1145/3447818.3460360 Alex Broihi...

  39. [2022]

    https://gawron.sdsu.edu/python_for_ss

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.