(apologies for breaking the thread; I only just subscribed) I offered an opinion on this excellent little patch to Caolán on IRC, basically that I thought the last foreach()/chop combo would be better written as a join. A minor nit, but probably not with much speed benefit.
The more perlish version of optimize_list() would probably look more like this: sub optimize_list { my ($longlist) = @_; $longlist =~ s/^\s+//; $longlist =~ s/\s+$//; my %seen; my @shortlist = sort grep { ! $seen{$_}++; } split(/\s*,\s*/, $longlist); return join(',', @shortlist); } grep is quasi-functional, but the nicest way of operating on arrays of things rather than doing string ops. In general, doing a lot of text operations - like running regexes over a string that you later split anyway - will tend to slow things down a bit, although I would doubt any difference between my version and Jordan's would be amazingly significant unless the lists are quite long. I haven't looked at a huge amount of the installer, but it might be that internally using strings less and data structures more could be used to speed it up a fair bit: having a look around, there's a long of string building and stuff going on and it's not really clear that's usually a win. It might be worth dumping out some of the main datastructures from that cruft to actually see what's going on... Ta Alex. -- This message was scanned by Better Hosted and is believed to be clean. http://www.betterhosted.com _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice