In src/tagmanager/tm_query.c:

> +	GPtrArray *ret;
> +
> +	sort_options.sort_attrs = NULL;
> +	/* tags_array isn not needed by tm_tag_compare(), but for tm_search_cmp() */
> +	sort_options.tags_array = NULL;
> +	sort_options.first = TRUE;
> +
> +	foreach_ptr_array(s, i, q->names)
> +	{
> +		TMTag **ptag;
> +		sort_options.cmp_len = s->len;
> +		if (q->data_sources & TM_QUERY_SOURCE_GLOBAL_TAGS)
> +		{
> +			tags = tm_tags_find(q->workspace->global_tags, s->str, s->len, &ntags);
> +			foreach_c_array(ptag, tags, ntags)
> +				g_queue_insert_sorted(&res, *ptag, tag_compare_ptr, &sort_options);

since the insertion point can be found with bisection

It couldn't as lists don't allow random access. The only way is basically to traverse the whole list up to the insertion point. If you knew the data set you could imagine making a guess at whether it's "close to" the end/start and start there, but that's as good as it gets AFAIK.

Sorting is a different story, because you can sort several items at once if you find interesting properties on them, and can take clever paths in some cases, but that doesn't work with a single insertion.

The array still has the slight disadvantage that it must be resized when adding items exceeding the lenght, but this is not a problem here.

Yeah well, it's not so much worse than allocating the whole array at the end as GPtrArray is not so stupid and grows in chunks.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.