[PD] sssad slowness

[Enrique Erne]

Enrique Erne wrote:
> Frank Barknecht wrote:
>> Hallo,
>> Enrique Erne hat gesagt: // Enrique Erne wrote:
>>
>>> i'm pretty sure it's the singleton it dynamically creates stuff onload.
>>
>> The singleton is needed to filter out duplicate keys-value-pairs,
>> which is necessary as sssad was designed to also work with sequential
>> containers like textfile or message boxes, but only with hash-type
>> containers like [pool].
>>
>> So [sssad] cannot remove the [singleton]. 
> 
> Hi Frank
> 
> sorry i was not very specific. in fact i did replace the singleton with 
> a little mechanism onload that checks if it is the first and opens up 
> the spigot. all other instances with the same key, that load after the 
> first, wont open the spigot.
> 
> i think it behaves the same. please check the sssad-help and see inside 
> the toggle []<-first
> 
> my naming is probably bad but if there are no other problems and you 
> approve it would be nice if you could include it into the main version.
>

i did some testing with sssad-help.pd and the modified sssad.

1) inside the [sssad key] only the first (most top) instance of sssad 
has the active toggle. i guess that's due to creation order.

2) [pd SSAD-globals] set->SSSAD_ADMIN prints
@key_3: 7
@key_2: 7
@key_1: 7

3) [pd SSAD-globals] activate SSSAD_ADMIN then save->SSSAD_ADMIN prints
SSSAD_ADMIN: save
SSSAD_ADMIN: list persist key 7

i think that is the correct behavior. the only thing that bothers me is 
the naming. maybe it would be better to replace the mechanism with the 
original. value $1.SSSAD.req +1 sel 0 etc.

what do you think?

eni