> On Mar 26, 2014, at 12:31 PM, Thomas Jackson wrote:
>
> The biggest performance gain I see of separate regexes is that I can
> execute the unique domain regexes which should resolve to a list of path
> regexes. This should be pretty big performance wise as a lot of rules in
> large remaps hav
The biggest performance gain I see of separate regexes is that I can
execute the unique domain regexes which should resolve to a list of path
regexes. This should be pretty big performance wise as a lot of rules in
large remaps have the same domain which may or may not be a regex.
On Mar 26, 2014 6
> On Mar 26, 2014, at 2:02 AM, Brian Geffon wrote:
>
> Thomas, I somewhat agree: my guess would be the additional regexes would
> likely cancel any performance gain there.
>
> Does anyone else have feedback or comments?
The other argument for this is that with separate regexes, you don't hav
Thomas, I somewhat agree: my guess would be the additional regexes would
likely cancel any performance gain there.
Does anyone else have feedback or comments?
Brian
On Tuesday, March 25, 2014, Thomas Jackson wrote:
> Another consideration for having >1 regex (which may or may not be
> prematur
Another consideration for having >1 regex (which may or may not be
premature optimization) is that if you have seperate regexes we can create
hash maps similar to how maps work (a hashmap of domain_regex -> list of
path regexes) which would make overall remap performance faster/better.
On Tue, Ma
Right.
On Tuesday, March 25, 2014, Leif Hedstrom wrote:
>
> On Mar 25, 2014, at 7:51 PM, Brian Geffon
> >
> wrote:
>
> > What Thomas called Question #1 -- 1 Regex.
> >
>
> Makes sense to have them combined. Assuming groups etc. works, that allows
> you to do e.g.
>
>regex_map http://(.*)\.o
On Mar 25, 2014, at 7:51 PM, Brian Geffon wrote:
> What Thomas called Question #1 -- 1 Regex.
>
Makes sense to have them combined. Assuming groups etc. works, that allows you
to do e.g.
regex_map http://(.*)\.ogre\.com/([^/]+)/(.*) http://$2/$1/$3
or some such. i.e. take parts from the
What Thomas called Question #1 -- 1 Regex.
Brian
On Tuesday, March 25, 2014, Leif Hedstrom wrote:
>
> On Mar 25, 2014, at 7:42 PM, Brian Geffon >
> wrote:
>
> > I personally vote for regexing everything until we get around to
> finalizing
> > lua config, I also vote for this being the one who w
On Mar 25, 2014, at 7:42 PM, Brian Geffon wrote:
> I personally vote for regexing everything until we get around to finalizing
> lua config, I also vote for this being the one who will end up writing the
> code :)
Which option is that?
— Leif
I personally vote for regexing everything until we get around to finalizing
lua config, I also vote for this being the one who will end up writing the
code :)
Brian
On Tuesday, March 25, 2014, James Peach wrote:
> On Mar 25, 2014, at 3:28 PM, Leif Hedstrom >
> wrote:
>
> >
> > On Mar 25, 2014,
On Mar 25, 2014, at 3:28 PM, Leif Hedstrom wrote:
>
> On Mar 25, 2014, at 4:08 PM, James Peach wrote:
>
>> On Mar 25, 2014, at 1:50 PM, Thomas Jackson wrote:
>>
>>> Here at LinkedIn we've been using regular remap.config for a while (with
>>> all our map options). One thing we've been looking
On Mar 25, 2014, at 4:08 PM, James Peach wrote:
> On Mar 25, 2014, at 1:50 PM, Thomas Jackson wrote:
>
>> Here at LinkedIn we've been using regular remap.config for a while (with
>> all our map options). One thing we've been looking into recently is path
>> based regexes (which regex_remap sup
On Mar 25, 2014, at 1:50 PM, Thomas Jackson wrote:
> Here at LinkedIn we've been using regular remap.config for a while (with
> all our map options). One thing we've been looking into recently is path
> based regexes (which regex_remap supports). While looking into it we found
> a few shortcoming
Here at LinkedIn we've been using regular remap.config for a while (with
all our map options). One thing we've been looking into recently is path
based regexes (which regex_remap supports). While looking into it we found
a few shortcomings of the plugin-- and decided it would probably be better
for
14 matches
Mail list logo
