{"slug": "from-5-seconds-to-1-2-milliseconds-rewriting-a-combinatorial-optimizer-with", "title": "From 5 Seconds to 1.2 Milliseconds: Rewriting a Combinatorial Optimizer with GitHub Copilot", "summary": "Croatian open-source grocery price tracker Cijene reduced its shopping cart optimization time from 5 seconds to 1.2 milliseconds by rewriting the backend with GitHub Copilot. The project, which won first place at a national hackathon, now serves thousands of Croatian families by optimizing entire shopping lists across 14 major grocery chains based on location and preferences. The developer refactored the Python API from a naive exact solver into an asynchronous architecture with bitmask validation and pre-indexed price lookups to handle concurrent production traffic.", "body_md": "*This is a submission for the GitHub Finish-Up-A-Thon Challenge*\n\n**Cijene** (\"Prices\") is Croatia's premier open-source grocery price tracker and shopping cart optimizer, designed to help families fight double-digit inflation. It began as a hackathon prototype that won first place at a national software development competition in Croatia, built under high-pressure, 24-hour constraints. Since then, it has evolved into a production-ready application that serves thousands of Croatian families, allowing them to track, compare, and optimize their grocery expenses.\n\nThe core innovation of Cijene is its **Košarica (Smart Shopping Cart Optimizer)**. Instead of simply comparing prices item-by-item, Cijene optimizes a user's entire shopping list across all major Croatian grocery chains (including Konzum, Lidl, Spar, Kaufland, Plodine, Tommy, Studenac, Eurospin, Metro, Žabac, Vrutak, Ribola, and NTL) based on their geographical location, search radius, and shopping preferences.\n\nUsers can choose between three optimization modes:\n\nBy refactoring the backend API and redesigning the core cart optimizer from the ground up, we turned a struggling prototype into a highly scalable, enterprise-grade system capable of handling concurrent production traffic.\n\nBelow you will find the links, interactive video walkthrough, and screenshots demonstrating Cijene's live optimization engine, user interface, and real-time savings calculations.\n\nIn the original competition prototype, the Python API service struggled under even minor loads. The shopping cart calculation function was a massive performance bottleneck. The old algorithm utilized a naive exact solver: to optimize a cart of NN N items across SS S nearby stores, it generated and evaluated every single combination of stores up to size KK K (where K≤5K \\le 5 K≤5 ).\n\nIn a dense urban area like Zagreb, with 28+ stores within a 15 km radius and a store limit of 5, the number of combinations exploded to:\n\nFor **every single combination**, the prototype:\n\n`product_prices.get(store_id)`\n\n) to check availability and find the minimum price.`signature = tuple((product_id, assignment[product_id]) for product_id in sorted(assignment))`\n\nto eliminate duplicate solutions.This approach resulted in massive memory allocation overhead, excessive garbage collection cycles, and CPU starvation. A simple 10-item cart in a dense area took **2 to 5 seconds** to execute. Under concurrent user traffic, this synchronous blocking behavior quickly led to request timeouts and server crashes.\n\nTo transition the prototype to a production-grade system, we refactored the backend into a highly optimized, asynchronous architecture. The optimization pipeline was completely rewritten to incorporate advanced algorithms and data structures:\n\nThe optimizer now begins with a pre-analysis pass that scans the cart items and identifies \"mandatory stores\"—stores that are the *only* option within the user's radius for at least one item. If the number of mandatory stores exceeds the user-configured store limit (\nM>KM > K M>K\n), the algorithm immediately exits. Otherwise, those\nMM M\nstores are fixed, and we only generate combinations of size\nK−MK - M K−M\nfrom the remaining non-mandatory stores.\n\nFor instance, if\nM=2M = 2 M=2\nand\nK=5K = 5 K=5\n, we only need to choose 3 additional stores from the remaining 26 non-mandatory options:\n\nRather than verifying cart feasibility in a nested loop using dictionary lookups, we mapped each product in the cart to a specific bit index in an integer (e.g., product\nii i\ncorresponds to `1 << i`\n\n).\n\n`if subset_mask != target_mask: continue`\n\n.\nIf a subset is infeasible, the check fails in a single CPU cycle, completely skipping expensive price calculations.We replaced nested string-hashed dictionary lookups in the hot loop with contiguous memory structures. Store prices are now pre-indexed into a flat tuple of floats where the position corresponds to the product's index in the cart. Finding the best price for product\nii i\nin a store subset is now a direct array lookup:\n\n```\nprice = store_prices_indexed[store_id][i]\n```\n\nThis is an\nO(1)O(1) O(1)\noperation that bypasses Python's dictionary hashing overhead entirely. Furthermore, store distances are pre-cached in a flat dictionary (`store_distances`\n\n) to prevent redundant distance recalculations.\n\nIn `_prune_dominated_stores`\n\n, stores are sorted by distance first. For any two stores\nAA A\nand\nBB B\n, if store\nBB B\nis further away than store\nAA A\nand does not offer a better price for any product,\nBB B\nis pruned as \"dominated.\" Because the stores are sorted by distance, the algorithm breaks out of the loop early the moment `distance_b > distance_a`\n\n, saving thousands of redundant iterations.\n\nWhen the number of stores after pruning still exceeds the enumeration limit (`enum_store_limit = 12`\n\n), exact enumeration is bypassed in favor of a heuristic solver (`_heuristic_optimize`\n\n). The heuristic:\n\n`_improve_candidate_by_swaps`\n\n), iteratively swapping active stores with high-ranking pool stores to minimize the multi-objective score (cost, distance, store count).\nThis heuristic solver guarantees a near-optimal recommendation in less than To protect the backend from duplicate queries, we implemented `CartOptimizeCache`\n\nusing Redis and an in-memory TTL fallback. To ensure high cache hit rates for geographic queries, we implemented **location bucketing**. Instead of caching on raw GPS coordinates, we round latitude and longitude to a configurable grid (~200 meters):\n\n``` php\ndef _bucket_coordinate(latitude: float, longitude: float) -> tuple[float, float]:\n    lat_step = bucket_size_m / 111_320.0\n    lon_scale = max(0.01, cos(radians(latitude)))\n    lon_step = bucket_size_m / (111_320.0 * lon_scale)\n    return (round(round(latitude / lat_step) * lat_step, 6), round(round(longitude / lon_step) * lon_step, 6))\n```\n\nIf multiple users in the same neighborhood search for the same cart items, they hit the cache even if their exact coordinates differ by a few meters.\n\nTo align recommendations with actual user behavior, we added a feedback endpoint (`POST /v1/cart/optimize/feedback`\n\n) and run tracking database tables. If the user acceptance rate for a particular optimization mode falls below a threshold (e.g., 25% over a 30-day window), the system dynamically adjusts the weights (cost, distance, store count) in\n±0.05\\pm 0.05 ±0.05\nincrements, automatically fine-tuning the algorithm to user preferences over time.\n\nGitHub Copilot acted as an expert pair programmer throughout the refactoring process. It didn't just write boilerplate code; it helped redesign our core data structures and mathematical models.\n\nHere is how Copilot accelerated our development and achieved the 1000x speedup:\n\nWhile explaining the bottleneck of the subset feasibility check to Copilot, it suggested mapping the cart items to a bitmask and utilizing bitwise operations for set cover evaluation. It generated the code to transform our complex product lists into bitwise integers:\n\n```\nproduct_to_bit = {item.product_id: (1 << idx) for idx, item in enumerate(cart_items)}\ntarget_mask = (1 << num_products) - 1\n```\n\nThis suggestion eliminated the slow set-union logic and replaced it with ultra-fast bitwise math, reducing the feasibility checking time to near-zero.\n\nWhen writing the heuristic solver for large store sets, Copilot co-authored the 2-opt local search swap loop (`_improve_candidate_by_swaps`\n\n). It perfectly implemented the logic to remove a store from the active subset, find the best replacement candidate from the ranked pool, evaluate if the swap improved the multi-objective utility score, and apply the swap. This ensured that even when falling back to the heuristic solver, our recommendation quality remained exceptionally high.\n\nTo verify the performance improvements, Copilot helped write `cart_optimizer_benchmark.py`\n\n. The tool generates mock shopping carts, simulates store coordinates, assigns randomized prices, and benchmarks the latency and quality gap between the exact and heuristic solver across different optimization modes.\n\nRunning this benchmark confirmed:\n\nCopilot analyzed our database interaction layer (`psql.py`\n\n) and identified a sub-optimal SQL join. It suggested refactoring the product price query to target the primary key index `prices.store_id`\n\ndirectly instead of referencing the outer joined `stores.id`\n\n. This simple suggestion cut database query latency in half, allowing the API to fetch price matrices for large carts in under 15 ms.\n\nWith GitHub Copilot, we successfully converted a slow hackathon prototype into a highly optimized, production-ready backend. Cijene now runs on a lean, asynchronous stack that provides real-time grocery savings recommendations to thousands of users, proving that with the right tools, even complex combinatorial problems can be optimized to run in milliseconds.", "url": "https://wpnews.pro/news/from-5-seconds-to-1-2-milliseconds-rewriting-a-combinatorial-optimizer-with", "canonical_source": "https://dev.to/karilca/from-5-seconds-to-12-milliseconds-rewriting-a-combinatorial-optimizer-with-github-copilot-342o", "published_at": "2026-06-05 14:25:00+00:00", "updated_at": "2026-06-05 14:42:42.809156+00:00", "lang": "en", "topics": ["ai-tools", "ai-products", "ai-startups", "generative-ai"], "entities": ["Cijene", "GitHub Copilot", "Konzum", "Lidl", "Spar", "Kaufland", "Plodine", "Tommy"], "alternates": {"html": "https://wpnews.pro/news/from-5-seconds-to-1-2-milliseconds-rewriting-a-combinatorial-optimizer-with", "markdown": "https://wpnews.pro/news/from-5-seconds-to-1-2-milliseconds-rewriting-a-combinatorial-optimizer-with.md", "text": "https://wpnews.pro/news/from-5-seconds-to-1-2-milliseconds-rewriting-a-combinatorial-optimizer-with.txt", "jsonld": "https://wpnews.pro/news/from-5-seconds-to-1-2-milliseconds-rewriting-a-combinatorial-optimizer-with.jsonld"}}