| Hannu Krosing 2005-08-10, 7:25 am |
| On T, 2005-08-09 at 17:07 -0400, Christopher Browne wrote:
> I'm not sure a temp table will work, based on where the actionseq values
> come from :-(.
If the usual case is also a continuous list of integers, I see no real
need for making it more complex. It would have been the last effort if
the integers had been sparse but still plenty;
> Alas, the problem is that elegant Pythonic answers aren't much good for
> helping with code in C, as C hasn't got the string parsing capabilities,
> and allocating memory dynamically requires a fair bit of work "by hand."
I _tried_ to write as C-like (and not really elegant :) ) code as
possible, so that it would be useful for actual C coding - there are
only 4 variables ( n, n1, range_start, range_end ), the list is scanned
once and the actual query parts can be added also continuously when
ready.
And I guess that these integers come from some previous query, so they
are also kind of "pre-allocated".
> I've got a FSM whiteboarded that will efficiently parse the list of
> integers (when you can use an FSM, your problem has "blazingly fast"
> written all over it!); I'll have to do a bit of thinking about what to
> do about processing those integers :-).
>
> I now know the FSM part is easy; I'll have to sleep on the rest...
my python code was just for testing the processing algorithm (I got it
work right in 4 tries :)
....
> It's excluding entries that aren't in the present SYNCs being processed.
>
> I wouldn't be surprised if you'd get better result by either:
>
> a) Forcing the slon to do one sync at a time ---> -g 1
I tried that (but only after the damage was done).
> b) Forcing the slon to do a whole lot of syncs at a time --> -g 1000
Usually I run with -g 100
--
Hannu Krosing <hannu-7C/ iILuz2RdeoWH0uzbU5w@
public.gmane.org>
|