Abstract

Native functional-style querying extensions for programming languages (e.g., LINQ or Java 8 streams) are widely considered as declarative. However, their very limited degree of optimisation when dealing with local collection processing contradicts this statement. We show that developers constructing complex LINQ queries or combining queries expose themselves to the risk of severe performance deterioration. For an inexperienced programmer, a way of getting an appropriate query form can be too complicated. Also, a manual query transformation is justified by the need of improving performance, but achieved at the expense of reflecting an actual business goal. As a result, benefits from a declarative form and an increased level of abstraction are lost. In this paper, we claim that moving of selected methods for automated optimisation elaborated for declarative query languages to the level of imperative programming languages is possible and desired. We propose an optimisation method for collection-processing constructs based on higher-order functions through factoring out of free expressions in order to avoid unnecessary multiple calculations. We have implemented and verified this idea as a simple proof-of-concept LINQ optimiser library.

Highlights

  • SINCE the release of LINQ (Language-Integrated Query) for the Microsoft .NET platform in 2007, there has been a significant progress in the topic of extending programming languages with native querying capabilities [1]

  • We show that developers constructing complex LINQ queries or combining queries expose themselves to the risk of severe performance deterioration

  • Query languages are usually declarative and their semantics often bases on some forms of algebras or logics; these languages operate mostly on collections of persistent data

Read more

Summary

INTRODUCTION

SINCE the release of LINQ (Language-Integrated Query) for the Microsoft .NET platform in 2007, there has been a significant progress in the topic of extending programming languages with native querying capabilities [1]. If the query addresses a native collection of objects, its execution is severely inefficient as the nested subquery, searching for prices of products named Ikura, is unnecessarily evaluated for each product addressed by the outer query This task could be resolved in a time linearly proportional to the collection's cardinality, the LINQ engine induces an outer loop and a nested loop, both iterating over the products’ collection. Without knowledge on how a query engine works in a context of given data, the optimisation process is too complex and time-consuming This is true if a programmer wants to preserve semantics and properties of his query construct. The problem that this paper deals with is not limited to LINQ It extends to dozens of programming environments that support functional-style operations on collections of elements, such as filter, map or reduce.

RELATED WORK AND THE STATE-OF-THE-ART
CHARACTERISTICS OF LANGUAGE-INTEGRATED QUERY CONSTRUCTS
Evaluation of Independent Subqueries
Factoring Out Constructs Executed Immediately
Consequences of Changing the Evaluation Order
FACTORING OUT FREE EXPRESSIONS
Formalising Optimisation
PERFORMANCE TESTS
Free Expression Detection
Applying Factoring Out
VIII. SUMMARY
Full Text
Published version (Free)

Talk to us

Join us for a 30 min session where you can share your feedback and ask us any queries you have

Schedule a call