﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Frederik commented on Algorithms, joins and performance</title><description>And what if you use a HybridDictionary ?
  
With large collections, a Hashtable is more performant.
  
  
The HybridDictionary uses internally a hashtable when the collection is large, and a ListDictionary when the collection is small.
  
  
What are the results if you use a HybridDictionary ?
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment7</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment7</guid><pubDate>Thu, 17 Jan 2008 11:31:14 GMT</pubDate></item><item><title>Felix Gartsman commented on Algorithms, joins and performance</title><description>Have you tried Perfect Hashing? You know the keys in advance, and access them much more times then their count. You can get really fast lookup.
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment6</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment6</guid><pubDate>Tue, 15 Jan 2008 09:35:09 GMT</pubDate></item><item><title>Bunter commented on Algorithms, joins and performance</title><description>Using DSA database was exactly what I refering to. In memory operations quickly become impossible if your size of your data grows. Then you would have to implement a lot of functionality most DB engines offer otb. But that ain't su much fun :)
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment5</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment5</guid><pubDate>Tue, 15 Jan 2008 08:55:34 GMT</pubDate></item><item><title>Ayende Rahien commented on Algorithms, joins and performance</title><description>I considered this, sure.
  
See previous discussion on the blog. Right now I don't need it, but it is the logical next step, I think
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment4</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment4</guid><pubDate>Mon, 14 Jan 2008 21:05:43 GMT</pubDate></item><item><title>Arne Claassen commented on Algorithms, joins and performance</title><description>Have you considered using a local DB as a temp store? At MP3.com we used unix join/sort/files/cut commands on text file for ETL because it beat in-memory operations. I recently talked to one of the warehouse guys from those days and he told me that he now uses SQL Lite as a local store for doing his transformations and found it to beat in memory operations.
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment3</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment3</guid><pubDate>Mon, 14 Jan 2008 20:51:53 GMT</pubDate></item><item><title>Ayende Rahien commented on Algorithms, joins and performance</title><description>Bunter,
  
In this case, I am doing a join of items from file into the results of a web service calls and then joining that to a DB call.
  
The result goes to a second DB.
  
The context is an ETL tool, not a DB
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment2</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment2</guid><pubDate>Mon, 14 Jan 2008 18:52:25 GMT</pubDate></item><item><title>Bunter commented on Algorithms, joins and performance</title><description>Strange that you are doing this in memory instead of having database handle it. 
</description><link>http://ayende.com/3099/algorithms-joins-and-performance#comment1</link><guid>http://ayende.com/3099/algorithms-joins-and-performance#comment1</guid><pubDate>Mon, 14 Jan 2008 18:26:19 GMT</pubDate></item></channel></rss>